Re: DROP OWNED BY fails to clean out pg_init_privs grants

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: DROP OWNED BY fails to clean out pg_init_privs grants
Date: 2024-04-29 19:15:08
Message-ID: 1372432.1714418108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 28 Apr 2024, at 20:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... It's a little bit
>> nasty to look at the ACL column of pg_init_privs, because that text
>> involves the bootstrap superuser's name which is site-dependent.
>> What I did to try to make the test stable is
>> replace(initprivs::text, current_user, 'postgres') AS initprivs

> Maybe that part warrants a small comment in the testfile to keep it from
> sending future readers into rabbitholes?

Agreed.

>> This is of course not bulletproof: with a sufficiently weird
>> bootstrap superuser name, we could get false matches to parts
>> of "regress_dump_test_role" or to privilege strings. That
>> seems unlikely enough to live with, but I wonder if anybody has
>> a better idea.

> I think that will be bulletproof enough to keep it working in the buildfarm and
> among 99% of hackers.

It occurred to me to use "aclexplode" to expand the initprivs, and
then we can substitute names with simple equality tests. The test
query is a bit more complicated, but I feel better about it.

v3 attached also has a bit more work on code comments.

regards, tom lane

Attachment Content-Type Size
v3-initprivs-dependency-fix.patch text/x-diff 42.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-29 19:17:34 Re: Extension Enhancement: Buffer Invalidation in pg_buffercache
Previous Message Heikki Linnakangas 2024-04-29 19:06:27 Re: Direct SSL connection with ALPN and HBA rules