Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit5342874

Browse files
committed
Fix failure to track role dependencies of pg_init_privs entries.
If an ACL recorded in pg_init_privs mentions a non-pinned role,that reference must also be noted in pg_shdepend so that we knowthat the role can't go away without removing the ACL reference.Otherwise, DROP ROLE could succeed and leave dangling entriesbehind, which is what's causing the recent upgrade-check failureson buildfarm member copperhead.This has been wrong since pg_init_privs was introduced, but it'sescaped notice because typical pg_init_privs entries would onlymention the bootstrap superuser (pinned) or at worst the ownerof the extension (who can't go away before the extension does).We lack even a representation of such a role reference forpg_shdepend. My first thought for a solution was entries listingpg_init_privs in classid, but that doesn't work because then there'snoplace to put the granted-on object's classid. Rather than addinga new column to pg_shdepend, let's add a new deptype codeSHARED_DEPENDENCY_INITACL. Much of the associated boilerplatecode can be cribbed from code for SHARED_DEPENDENCY_ACL.A lot of the bulk of this patch just stems from the new need to passthe object's owner ID to recordExtensionInitPriv, so that we canconsult it while updating pg_shdepend. While many callers have thatat hand already, a few places now need to fetch the owner ID of anarbitrary privilege-bearing object. For that, we assume that thereis a catcache on the relevant catalog's OID column, which is anassumption already made in ExecGrant_common so it seems okay here.We do need an entirely new routine RemoveRoleFromInitPriv to performcleanup of pg_init_privs ACLs during DROP OWNED BY. It's analogousto RemoveRoleFromObjectACL, but we can't share logic because thatfunction operates by building a command parsetree and invokingexisting GRANT/REVOKE infrastructure. There is of course no SQLcommand that would update pg_init_privs entries when we're not inprocess of creating their extension, so we need a routine that cando the updates directly.catversion bump because this changes the expected contents ofpg_shdepend. For the same reason, there's no hope of back-patchingthis, even though it fixes a longstanding bug. Fortunately, thecase where it's a problem seems to be near nonexistent in the field.If it weren't for the buildfarm breakage, I'd have been content toleave this for v18.Patch by me; thanks to Daniel Gustafsson for review and discussion.Discussion:https://postgr.es/m/1745535.1712358659@sss.pgh.pa.us
1 parentdd01834 commit5342874

File tree

8 files changed

+549
-23
lines changed

8 files changed

+549
-23
lines changed

‎doc/src/sgml/catalogs.sgml

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7184,6 +7184,20 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
71847184
</listitem>
71857185
</varlistentry>
71867186

7187+
<varlistentry>
7188+
<term><symbol>SHARED_DEPENDENCY_INITACL</symbol> (<literal>i</literal>)</term>
7189+
<listitem>
7190+
<para>
7191+
The referenced object (which must be a role) is mentioned in a
7192+
<link linkend="catalog-pg-init-privs"><structname>pg_init_privs</structname></link>
7193+
entry for the dependent object.
7194+
(A <symbol>SHARED_DEPENDENCY_INITACL</symbol> entry is not made for
7195+
the owner of the object, since the owner will have
7196+
a <symbol>SHARED_DEPENDENCY_OWNER</symbol> entry anyway.)
7197+
</para>
7198+
</listitem>
7199+
</varlistentry>
7200+
71877201
<varlistentry>
71887202
<term><symbol>SHARED_DEPENDENCY_POLICY</symbol> (<literal>r</literal>)</term>
71897203
<listitem>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp