Re: replacing role-level NOINHERIT with a grant-level option
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joe Conway <mail@joeconway.com>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-06-22T20:30:36Z
Lists: pgsql-hackers
Attachments
- v1-0002-Replace-NO-INHERIT-property-for-roles-with-a-gran.patch (application/octet-stream) patch v1-0002
- v1-0001-Fake-version-stamp.patch (application/octet-stream) patch v1-0001
On Thu, Jun 2, 2022 at 1:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Point 2 would cause every existing pg_dumpall script to fail, which
> seems like kind of a large gotcha. Less unpleasant alternatives
> could include
>
> * Continue to accept the syntax, but ignore it, maybe with a WARNING
> for the alternative that doesn't correspond to the new behavior.
>
> * Keep pg_authid.rolinherit, and have it act as supplying the default
> behavior for subsequent GRANTs to that role.
Here's a rather small patch that does it the first way.
I know that Peter Eisentraut didn't like the idea of removing the
role-level option, but I don't know why, so I don't know whether doing
this the second way instead would address his objection.
I suppose if we did it the second way, we could make the syntax GRANT
granted_role TO recipient_role WITH INHERIT { TRUE | FALSE | DEFAULT
}, and DEFAULT would copy the current value of the rolinherit
property, so that changing the rolinherit property later would not
affect previous grants. The reverse is also possible: with the same
syntax, the rolinherit column could be changed from bool to "char",
storing t/f/d, and 'd' could mean the value of the rolinherit property
at time of use; thus, changing rolinherit would affect previous grants
performed using WITH INHERIT DEFAULT but not those that specified WITH
INHERIT TRUE or WITH INHERIT FALSE.
In some sense, this whole scheme seems backwards to me: wouldn't it be
more natural if the default were based on the role being granted
rather than the role to which it is granted? If I decide to GRANT
some_predefined_role TO some_user, it seems like I am really likely to
want the INHERIT behavior, whereas if I GRANT some_other_user TO
some_user, it could go either way depending on the use case. But this
may be water under the bridge: introducing a way to set the default
that is backwards from the way that the current role-level property
works may be too confusing to be worthy of any consideration at all.
Thoughts?
--
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