From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Tying an object's ownership to datdba |
Date: | 2020-12-28 04:31:48 |
Message-ID: | 20201228043148.GA1053024@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
https://postgr.es/m/20201031163518.GB4039133@rfd.leadboat.com gave $SUBJECT as
one of the constituent projects for changing the public schema default ACL.
This feature stands on its own, hence the new thread. I showed syntax "ALTER
SCHEMA public OWNER TO DATABASE_OWNER" and anticipated a new RoleSpecType.
That was fine for in-memory representation, but it lacked a value to store in
pg_namespace.nspowner. That led me to instead add a default role,
"pg_database_owner". That way, user queries joining owner columns to
pg_authid need no modification. Also, user.c changes were trivial, and
pg_dump needed no changes. The role's membership consists, implicitly, of the
current database owner. The first patch refactors acl.c to reduce code
duplication, and the second patch adds the feature.
I ended up blocking DDL that creates role memberships involving the new role;
see reasons in user.c comments. Lifting those restrictions looked feasible,
but it was inessential to the mission, and avoiding unintended consequences
would have been tricky. Views "information_schema.enabled_roles" and
"information_schema.applicable_roles" list any implicit membership in
pg_database_owner, but pg_catalog.pg_group and psql \dgS do not. If this
leads any reviewer to look closely at applicable_roles, note that its behavior
doesn't match its documentation
(https://postgr.es/m/flat/20060728170615(dot)GY20016(at)kenobi(dot)snowman(dot)net)
This patch makes us read pg_database when reading pg_auth_members.
IndexScanOK() has been saying "during backend startup we have to be able to
use the pg_authid and pg_auth_members syscaches for authentication". While
that's true of pg_authid, I found no sign of pg_auth_members reads that early.
(The read in InitPostgres() -> CheckMyDatabase() -> pg_database_aclcheck()
happens after RelationCacheInitializePhase3(). In a physical walsender, which
never has a mature relcache, some SHOW commands make guc.c check
DEFAULT_ROLE_READ_ALL_SETTINGS. The walsender case, though it happens after
authentication, may necessitate IndexScanOK()'s treatment of pg_auth_members.)
For now, just in case I missed the early read, I've made IndexScanOK() treat
pg_database like pg_auth_members.
Thanks,
nm
Attachment | Content-Type | Size |
---|---|---|
dedup-roles_is_member_of-v1.patch | text/plain | 12.3 KB |
pg_database_owner-v1.patch | text/plain | 15.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2020-12-28 05:15:50 | Re: Parallel Inserts in CREATE TABLE AS |
Previous Message | Andy Fan | 2020-12-28 04:24:35 | Re: Cache relation sizes? |