Re: role self-revocation
Joshua Brindle <joshua.brindle@crunchydata.com>
From: Joshua Brindle <joshua.brindle@crunchydata.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>,
"David G. Johnston" <david.g.johnston@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-03-10T17:26:42Z
Lists: pgsql-hackers
On Thu, Mar 10, 2022 at 12:11 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Mar 10, 2022 at 11:19 AM Stephen Frost <sfrost@snowman.net> wrote: > > I disagree that ownership is needed that's not what the spec calls for > > either. What we need is more flexibility when it comes to the > > relationships which are allowed to be created between roles and what > > privileges come with them. To that end, I'd argue that we should be > > extending pg_auth_members, first by separating out membership itself > > into an explicitly tracked attribute (instead of being implicit in the > > existance of a row in the table) and then adding on what other > > privileges we see fit to add, such as the ability to DROP a role. We > > do need to remove the ability for a role who hasn't been explicitly > > given the admin right on another role to modify that role's membership > > too, as was originally proposed here. This also seems to more closely > > follow the spec's expectation, something that role ownership doesn't. > > I do not have a problem with more fine-grained kinds of authorization > even though I think there are syntactic issues to work out, but I > strongly disagree with the idea that we can't or shouldn't also have > role ownership. Marc invented it. Now Tom has invented it > independently. All sorts of other objects have it already. Trying to > make it out like this is some kind of kooky idea is not believable. > Yeah, it's not the most sophisticated or elegant model and that's why > it's good for us to also have other things, but for simple cases it is > easy to understand and works great. Ownership implies DAC, the ability to grant others rights to an object. It's not "kooky" to see roles as owned objects, but it isn't required either. For example most objects on a UNIX system are owned and subject to DAC but users aren't. Stephen's, and now my, issue with ownership is that, since it implies DAC, most checks will be bypassed for the owner. We would both prefer for everyone to be subject to the grants, including whoever created the role. Rather, we'd like to see a "creators of roles get this set of grants against the role by default" and "as a superuser I can revoke grants from creators against roles they created"
Commits
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 landed
-
Ensure that pg_auth_members.grantor is always valid.
- 6566133c5f52 16.0 landed
-
Remove the ability of a role to administer itself.
- 79de9842ab03 15.0 landed
-
Add tests of the CREATEROLE attribute
- e9d4001ec592 15.0 landed
-
Replace explicit PIN entries in pg_depend with an OID range test.
- a49d08123599 15.0 cited
-
Shore up ADMIN OPTION restrictions.
- fea164a72a7b 9.4.0 cited
-
Add pg_has_role() family of privilege inquiry functions modeled after the
- f9fd1764615e 8.1.0 cited
-
Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion
- 4b2dafcc0b1a 8.0.0 cited