Re: role self-revocation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>,
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-07T19:46:56Z
Lists: pgsql-hackers
On Mon, Mar 7, 2022 at 2:29 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > You mean the one that was based upon your "ooops"...I discounted that immediately because members cannot revoke their own membership in a group unless they were given WITH ADMIN OPTION on that group. Oh, hmm. That example might be backwards from the case I'm talking about. > The mere fact that the pg_hba.conf concern raised there hasn't been reported as a live issue suggests the lack of any meaningful design flaw here. Not really. The system is full of old bugs, just as all software system are, and the particular role self-administration behavior that is at issue here appears to be something that was accidentally introduced 16 years years ago in a commit that did something else and never scrutinized from a design perspective since then. Personally, I've been shocked by the degree to which this entire area seems to be full of design flaws and half-baked code. I mean, just the fact that the pg_auth_members.grantor can be left pointing to a role OID that no longer exists is pretty crazy, right? I don't think anyone today would consider something with that kind of wart committable. > That isn't to say that having a LOGIN role get an automatic temporary WITH ADMIN OPTION on itself is a good thing - but there isn't any privilege escalation vector here to be squashed. There is just a "DBAs should treat LOGIN roles as leaf nodes" expectation in which case there would be no superuser granted memberships to be removed. Well, we may not have found one yet, but that doesn't prove none exists. In any case, if we can agree that it's not necessarily a desirable behavior, that's good enough for me. (I still disagree with the idea that LOGIN roles have to be leaf nodes. We could have a system where that's true, but that's not how the system we actually have is designed.) -- 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