CREATEROLE and role ownership hierarchies
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Date: 2021-10-20T18:40:35Z
Lists: pgsql-hackers
Attachments
- v1-0001-Add-tests-of-the-CREATEROLE-attribute.patch (application/octet-stream) patch v1-0001
- v1-0002-Add-owners-to-roles.patch (application/octet-stream) patch v1-0002
- v1-0003-Give-role-owners-control-over-owned-roles.patch (application/octet-stream) patch v1-0003
- v1-0004-Restrict-power-granted-via-CREATEROLE.patch (application/octet-stream) patch v1-0004
- (unnamed) (text/plain)
These patches have been split off the now deprecated monolithic "Delegating superuser tasks to new security roles" thread at [1]. 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.)
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