Re: role self-revocation
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Dilger <mark.dilger@enterprisedb.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Joshua Brindle <joshua.brindle@crunchydata.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-03-09T21:23:48Z
Lists: pgsql-hackers
Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > On Wed, Mar 9, 2022 at 4:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > In my opinion, the right to > > > administer a role - regardless of whether or not it is a login role - > > > most naturally vests in the role that created it, or something in that > > > direction at least, if not that exact thing. > > > > This seems like a reasonable answer to me too: the creating role has admin > > option implicitly, and can then choose to grant that to other roles. > > Obviously some work needs to be done to make that happen (and we should > > see whether the SQL spec has some different idea). > > Well, the problem is that as far as I can see, the admin option is an > optional feature of membership. You can grant someone membership > without admin option, or with admin option, but you can't grant them > the admin option without membership, just like you can't purchase an > upgrade to first class without the underlying plane ticket. What would > the syntax look even like for this? GRANT foo TO bar WITH ADMIN OPTION > BUT WITHOUT MEMBERSHIP? Yikes. I've been meaning to reply to your other email regarding this, but I don't really agree that the syntax ends up being so terrible or difficult to deal with, considering we have these same general things for ALTER ROLE already and there hasn't been all that much complaining. That is, we have LOGIN and NOLOGIN, CREATEROLE and NOCREATEROLE, and we could have MEMBERSHIP and NOMEMBERSHIP pretty easily here if we wanted to. > But do we really have to solve this problem before we can clean up > this session exception? I hope not, because I think that's a much > bigger can of worms than this is. I do believe we can deal with the above independently and at a later time and go ahead and clean up the session excepton bit without dealing with the above at the same time. Thanks, Stephen
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