Re: role self-revocation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Joshua Brindle <joshua.brindle@crunchydata.com>,
Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-03-24T16:46:43Z
Lists: pgsql-hackers
On Fri, Mar 11, 2022 at 11:51 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Mar 11, 2022 at 11:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Note that either case would also involve making entries in pg_shdepend; > > although for the case of roles owned by/granted to the bootstrap > > superuser, we could omit those on the usual grounds that we don't need > > to record dependencies on pinned objects. > > That makes sense to me, but it still doesn't solve the problem of > agreeing on role ownership vs. WITH ADMIN OPTION vs. something else. Notwithstanding the lack of agreement on that point, I believe that what we should do for v15 is remove the session user self-administration exception. We have pretty much established that it was originally introduced in error. It later was found to be a security vulnerability, and that resulted in the exception being narrowed without removing it altogether. While there are differences of opinion on what the larger plan here ought to be, nobody's proposal plan involves retaining that exception. Neither has anyone offered a plausible use case for the current behavior, so there's no reason to think that removing it would break anything. However, it might. And if it does, I think it would be best if removing that exception were the *only* change in this area made by that release. If for v16 or v17 or v23 we implement Plan Tom or Plan Stephen or Plan Robert or something else, and along the way we remove that self-administration exception, we're going to have a real fire drill if it turns out that the self-administration exception was important for some reason we're not seeing right now. If, on the other hand, we remove that exception in v15, then if anything breaks, it'll be a lot easier to deal with. Worst case scenario we just revert the removal of that exception, which will be a very localized change if nothing else has been done that depends heavily on its having been removed. So I propose to commit something like what I posted here: http://postgr.es/m/CA+TgmobgeK0JraOwQVPqhSXcfBdFitXSomoebHMMMhmJ4gLonw@mail.gmail.com -- 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