Re: role self-revocation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Joshua Brindle <joshua.brindle@crunchydata.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-10T18:11:43Z
Lists: pgsql-hackers
On Thu, Mar 10, 2022 at 12:26 PM Joshua Brindle <joshua.brindle@crunchydata.com> wrote: > 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. I have no issue with anything you write in this paragraph. > 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. That sounds like MAC, which is usually something that sits on top of DAC and is enforced in addition to DAC, not a reason for DAC to not exist. > 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" If you create a table, you own it. You get a set of default permissions on the table which can be revoked either by you or by someone else, and you also have certain intrinsic rights over the object as owner which cannot be revoked - including the ability to re-grant yourself any previously-revoked permissions. I am not against the idea of trying to clean things up so that everything you can do with a table is a revocable privilege and you can be the owner without having any rights at all, including the right to give yourself other rights back, but I cannot believe that the idea of removing table ownership as a concept would ever gain consensus on this list. Therefore, I also do not think it is reasonable to say that we shouldn't introduce a similar concept for object types that don't have it yet, such as roles. But that's not to say that we couldn't decide to do something else instead, and that other thing might well be better. Do you want to sketch out a full proposal, even just what the syntax would look like, and share that here? And if you could explain how I could use it to create the mini-superusers that I'm trying to get out of this thing, even better. Thanks, -- Robert Haas EDB: http://www.enterprisedb.com
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