Re: CREATEROLE and role ownership hierarchies
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Joshua Brindle <joshua.brindle@crunchydata.com>,
Shinya Kato <Shinya11.Kato@oss.nttdata.com>,
"Bossart, Nathan" <bossartn@amazon.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Jeff Davis <pgsql@j-davis.com>
Date: 2022-01-11T21:24:53Z
Lists: pgsql-hackers
Attachments
- v5-0001-Add-tests-of-the-CREATEROLE-attribute.patch (application/octet-stream) patch v5-0001
- v5-0002-Add-owners-to-roles.patch (application/octet-stream) patch v5-0002
- v5-0003-Give-role-owners-control-over-owned-roles.patch (application/octet-stream) patch v5-0003
- v5-0004-Restrict-power-granted-via-CREATEROLE.patch (application/octet-stream) patch v5-0004
- v5-0005-Remove-grantor-field-from-pg_auth_members.patch (application/octet-stream) patch v5-0005
- (unnamed) (text/plain)
> On Jan 10, 2022, at 2:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> In general this looks good. Some nitpicks:
Thanks. Some responses...
> +/*
> + * Ownership check for a role (specified by OID)
> + */
> +bool
> +pg_role_ownercheck(Oid role_oid, Oid roleid)
>
>
> This is a bit confusing. Let's rename these params so it's clear which
> is the owner and which the owned role.
Yeah, I wondered about that when I was writing it. All the neighboring functions follow the pattern:
(Oid <something>_oid, Oid roleid)
so I followed that, but it isn't great. I've changed that in v5-0002 to use
(Oid owned_role_oid, Oid owner_roleid)
I wouldn't choose this naming in a green field, but I'm trying to stay close to the naming scheme of the surrounding functions.
> + * Note: In versions prior to PostgreSQL version 15, roles did not have
> owners
> + * per se; instead we used this test in places where an ownership-like
> + * permissions test was needed for a role.
>
>
> No need to talk about what we used to do. People who want to know can
> look back at older branches.
Removed in v5-0003.
> +bool
> +has_rolinherit_privilege(Oid roleid)
> +{
>
>
> This and similar functions should have header comments.
Header comments added for this and similar functions in v5-0004. This function was misnamed in prior patch sets; the privilege is INHERIT, not ROLINHERIT, so I also fixed the name in v5-0004.
> + /* Owners of roles have every privilge the owned role has */
>
> s/privlge/privilege/
Fixed in v5-0003.
> +CREATE ROLE regress_role_1 CREATEDB CREATEROLE REPLICATION BYPASSRLS;
>
>
> I don't really like this business of just numbering large numbers of
> roles in the tests. Let's give them more meaningful names.
Changed in v5-0001.
> + Role owners can change any of these settings on roles they own except
>
>
> I would say "on roles they directly or indirectly own", here and
> similarly in one or two other places.
Changed a few sentences of doc/src/sgml/ref/alter_role.sgml in v5-0004 as you suggest. Please advise if you have other locations in mind. A quick grep -i 'role owner' doesn't show any other relevant locations.
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