Re: Clarification on Role Access Rights to Table Indexes
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ayush Vatsa <ayushvatsa1810@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-09T21:18:03Z
Lists: pgsql-hackers, pgsql-general
Attachments
- 0001-pg_prewarm-privilege-test.patch (text/plain)
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
Commits
-
Fix privilege checks for pg_prewarm() on indexes.
- fae0ce5e318e 16.11 landed
- f146eb45cb1a 14.20 landed
- a0551bc5734b 17.7 landed
- 6c03ae8d6e81 15.15 landed
- 3ccf8e9ac96e 18.1 landed
- 208927e65692 19 (unreleased) landed
- 19a64f5676bb 13.23 landed
-
Fix lookup code for REINDEX INDEX.
- 079480dc2022 19 (unreleased) landed
-
Fix redefinition of typedef RangeVar.
- 15d7dded0e93 18.1 landed
-
Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
- c8af5019bee5 18.1 landed
- 688dc6299a5b 19 (unreleased) landed
-
dblink: Avoid locking relation before privilege check.
- c9b299f6df98 19 (unreleased) landed