Re: replacing role-level NOINHERIT with a grant-level option
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Joe Conway <mail@joeconway.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-01T13:05:16Z
Lists: pgsql-hackers
On Fri, Jul 1, 2022 at 8:22 AM Joe Conway <mail@joeconway.com> wrote: > Hmm, maybe I am misunderstanding something, but what I mean is something > like: > > 8<---------------- > CREATE TABLE t1(f1 int); > CREATE TABLE t2(f1 int); > > CREATE USER A; --defaults to INHERIT > CREATE USER B; > CREATE USER C; > > GRANT select ON TABLE t1 TO B; > GRANT select ON TABLE t2 TO C; > > GRANT B TO A; > GRANT C TO A; > > SET SESSION AUTHORIZATION A; > > -- works > SELECT * FROM t1; > -- works > SELECT * FROM t2; > > RESET SESSION AUTHORIZATION; > REVOKE INHERIT OPTION FOR C FROM A; > SET SESSION AUTHORIZATION A; > > -- works > SELECT * FROM t1; > -- fails > SELECT * FROM t2; > 8<---------------- > > So now A has implicit inherited privs for t1 but not for t2. Yeah, I anticipate that this would work in the way that you postulate here. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix a bug in roles_is_member_of.
- 0101f770a05b 16.0 landed
-
docs: Fix up some out-of-date references to INHERIT/NOINHERIT.
- 620ac285483f 16.0 landed
-
Allow grant-level control of role inheritance behavior.
- e3ce2de09d81 16.0 landed
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 cited
-
Document basebackup_to_shell.required_role.
- 26a0c025e233 15.0 landed