Re: CREATEROLE and role ownership hierarchies
Nathan Bossart <bossartn@amazon.com>
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Date: 2021-10-21T23:04:34Z
Lists: pgsql-hackers
On 10/20/21, 11:46 AM, "Mark Dilger" <mark.dilger@enterprisedb.com> wrote: > The purpose of these patches is to fix the CREATEROLE escalation > attack vector misfeature. (Not everyone will see CREATEROLE that > way, but the perceived value of the patch set likely depends on how > much you see CREATEROLE in that light.) Regarding the "attack vector misfeature" comment, I remember being surprised when I first learned how much roles with CREATEROLE can do. When I describe CREATEROLE to others, I am sure to emphasize the note in the docs about such roles being "almost-superuser" roles. CREATEROLE is a rather big hammer at the moment, so I certainly think there is value in reducing its almost-superuser-ness. I mentioned this in the other thread [0] already, but the first thing that comes to mind when I look at these patches is how upgrades might work. Will we just make the bootstrap superuser the owner for all roles when you first upgrade to v15? Also, are we just going to strip the current CREATEROLE roles of much of their powers? Maybe it's worth keeping a legacy CREATEROLE role attribute for upgraded clusters that could eventually be removed down the road. I'd also like to bring up my note about allowing users to transfer role ownership. When I tested the patches earlier, REASSIGN OWNED BY was failing with an "unexpected classid" ERROR. Besides REASSIGN OWNED BY, perhaps there should be another mechanism for transferring ownership on a role-by-role basis (i.e., ALTER ROLE OWNER TO). I haven't looked at this new patch set too closely, so my apologies if this has already been added. Nathan [0] https://postgr.es/m/53C7DF4C-8463-4647-9DFD-779B5E1861C4%40amazon.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