From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ayush Vatsa <ayushvatsa1810@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Clarification on Role Access Rights to Table Indexes
Date: Thu, 9 Oct 2025 16:18:03 -0500
Message-ID: <aOgmi6avE6qMw_6t@nathan> (raw)
In-Reply-To: <aOfXNAFkj_EFm-8q@nathan>
References: <149429.1741472260@sss.pgh.pa.us>
<Z8zwVmGzXyDdkAXj@nathan>
<279947.1741535285@sss.pgh.pa.us>
<Z88CB-vDehJ9rW8u@nathan>
<aNQVIVKarUipPcnW@nathan>
<3432170.1758730414@sss.pgh.pa.us>
<aNQhuRQfD3PlpeuT@nathan>
<8af53c6e8992aa706e63aafe60a3bcf100b524d1.camel@j-davis.com>
<7b0e2774cdcc8f522ac82f64a8d7266f353a5094.camel@j-davis.com>
<aOfXNAFkj_EFm-8q@nathan>
On Thu, Oct 09, 2025 at 10:39:32AM -0500, Nathan Bossart wrote:
> On Wed, Oct 08, 2025 at 08:28:01PM -0700, Jeff Davis wrote:
>> Actually, now I'm unsure. v4-0001 is taking a lock on the table before
>> checking privileges, whereas v4-0002 is going to some effort to avoid
>> that. Is that because the latter is taking a ShareLock?
>
> I was confused by this, too. We seem to go to great lengths to avoid
> taking a lock before checking permissions in RangeVarGetRelidExtended(),
> but in pg_prewarm() and this stats code, we are taking the lock first.
> pg_prewarm() can't use RangeVarGetRelid because you give it the OID, but
> I'm not seeing why stat_utils.c can't use it. We should probably fix this.
> I wouldn't be surprised if there are other examples.
I spent some time trying to change pg_prewarm() to check permissions before
locking and came up with the attached. There are certainly issues with the
patch, but this at least demonstrates the complexity required. I'm tempted
to say that this is more trouble than it's worth, but it does feel a little
weird to leave it as-is.
There's a similar pattern in get_rel_from_relname() in dblink.c, which also
seems to only be used with an AccessShareLock (like pg_prewarm). My best
guess from reading lots of code, commit messages, and old e-mails in the
archives is that the original check-privileges-before-locking work was
never completed.
I'm currently leaning towards continuing with v4 of the patch set. 0001
and 0003 are a little weird in that a concurrent change could lead to a
"could not find parent table" ERROR, but IIUC that is an extremely remote
possibility.
--
nathan
Attachments:
[text/plain] 0001-pg_prewarm-privilege-test.patch (0B, ../aOgmi6avE6qMw_6t@nathan/2-0001-pg_prewarm-privilege-test.patch)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: nathandbossart@gmail.com, pgsql@j-davis.com, tgl@sss.pgh.pa.us, ayushvatsa1810@gmail.com, robertmhaas@gmail.com, david.g.johnston@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: Clarification on Role Access Rights to Table Indexes
In-Reply-To: <aOgmi6avE6qMw_6t@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox