Re: replacing role-level NOINHERIT with a grant-level option
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Joe Conway <mail@joeconway.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-06-02T20:06:17Z
Lists: pgsql-hackers
On Thu, Jun 02, 2022 at 03:37:34PM -0400, Robert Haas wrote: > On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart <nathandbossart@gmail.com> wrote: >> I think we should also consider replacing role attributes with predefined >> roles. I'm not sure that this proposal totally prepares us for such a >> change, given role attributes apply only to the specific role for which >> they are set and aren't inherited. ISTM in order to support that, we'd >> need even more enhanced functionality. For example, if I want 'robert' to >> be a superuser, and I want 'joe' to inherit the privileges of 'robert' but >> not 'pg_superuser', you'd need some way to specify inheriting only certain >> privileges possessed by an intermediate role. > > I guess we could think about adding something like an ONLY clause, > like GRANT ONLY robert TO joe. I feel a little bit uncomfortable about > that, though, because it assumes that robert is a superuser but his > own privileges are distinguishable from those of the superuser. Are > they really? If I can assume robert's identity, I can presumably > Trojan my way into the superuser account pretty easily. I'll just > define a little trigger on one of his tables. I don't really see a way > where we can ever make it safe to grant a non-superuser membership in > a superuser role. I was primarily looking at this from the angle of preserving current behavior when upgrading from a version with role attributes to a version without them. If it's alright that a role with privileges of a superuser role begins being treated like a superuser after an upgrade, then we probably don't need something like GRANT ONLY. I bet that's how a lot of people expect role attributes to work, anyway. I'm sure I did at some point. > But even if there is a way, I think that is a separate patch from what > I'm proposing here. [NO]INHERIT only has to do with what privileges > you can exercise without SET ROLE. To solve the problem you're talking > about here, you'd need a way to control what privileges are conferred > in any manner, which is related, but different. I agree that the role-attribute-to-predefined-role stuff needs its own thread. I just think it's worth designing this stuff with that in mind. -- Nathan Bossart Amazon Web Services: https://aws.amazon.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