database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-07 00:36:50 +03:00
Code Activity

Add "pg_database_owner" default role.

Browse Source 
Membership consists, implicitly, of the current database owner.  Expect
use in template databases.  Once pg_database_owner has rights within a
template, each owner of a database instantiated from that template will
exercise those rights.

Reviewed by John Naylor.

Discussion: https://postgr.es/m/20201228043148.GA1053024@rfd.leadboat.com
This commit is contained in:
Noah Misch
2021-03-26 10:42:17 -07:00
parent f687bf61ed
commit a14a0118a1
11 changed files with 207 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
src/backend/commands/user.c
View File

@ -1496,6 +1496,18 @@ AddRoleMems(const char *rolename, Oid roleid,
rolename)));
}
/*
* The charter of pg_database_owner is to have exactly one, implicit,
* situation-dependent member. There's no technical need for this
* restriction. (One could lift it and take the further step of making
* pg_database_ownercheck() equivalent to has_privs_of_role(roleid,
* DEFAULT_ROLE_DATABASE_OWNER), in which case explicit,
* situation-independent members could act as the owner of any database.)
*/
if (roleid == DEFAULT_ROLE_DATABASE_OWNER)
ereport(ERROR,
errmsg("role \"%s\" cannot have explicit members", rolename));
/*
* The role membership grantor of record has little significance at
* present. Nonetheless, inasmuch as users might look to it for a crude
@ -1524,6 +1536,30 @@ AddRoleMems(const char *rolename, Oid roleid,
bool new_record_nulls[Natts_pg_auth_members];
bool new_record_repl[Natts_pg_auth_members];
/*
* pg_database_owner is never a role member. Lifting this restriction
* would require a policy decision about membership loops. One could
* prevent loops, which would include making "ALTER DATABASE x OWNER
* TO proposed_datdba" fail if is_member_of_role(pg_database_owner,
* proposed_datdba). Hence, gaining a membership could reduce what a
* role could do. Alternately, one could allow these memberships to
* complete loops. A role could then have actual WITH ADMIN OPTION on
* itself, prompting a decision about is_admin_of_role() treatment of
* the case.
*
* Lifting this restriction also has policy implications for ownership
* of shared objects (databases and tablespaces). We allow such
* ownership, but we might find cause to ban it in the future.
* Designing such a ban would more troublesome if the design had to
* address pg_database_owner being a member of role FOO that owns a
* shared object. (The effect of such ownership is that any owner of
* another database can act as the owner of affected shared objects.)
*/
if (memberid == DEFAULT_ROLE_DATABASE_OWNER)
ereport(ERROR,
errmsg("role \"%s\" cannot be a member of any role",
get_rolespec_name(memberRole)));
/*
* Refuse creation of membership loops, including the trivial case
* where a role is made a member of itself. We do this by checking to