Re: Clarification on Role Access Rights to Table Indexes
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, 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-13T22:11:38Z
Lists: pgsql-hackers, pgsql-general
On Mon, 2025-10-13 at 17:21 -0400, Tom Lane wrote: > I don't think so. Even AccessShareLock is enough to block another > session trying to acquire AccessExclusiveLock, and then not only > have you DoS'd that session, but everything else trying to access > the table will queue up behind the AccessExclusiveLock request. > So it's only not-a-problem if nothing anywhere in the system wants > non-sharable locks. I tried imagining how that could be a problem, but couldn't come up with anything. If the privilege check is right after the lock, then either: (a) The malicious AccessShareLock is granted, then is quickly released when the privilege check fails and the transaction aborts; or (b) The malicious AccessShareLock is queued behind a legitimate AccessExclusiveLock, in which case every other lock would be queued up as well. As soon as the AccessExclusiveLock is released, the AccessShareLock would be granted, but quickly released when the privilege check fails. For it to be a problem, the malicious lock needs to be strong enough to conflict with a lock level weaker than itself, i.e. ShareLock or stronger. I'm not sure we save anything by being lazier for weaker lock levels, so perhaps the point is irrelevant. But if I'm missing something, please let me know. Regards, Jeff Davis
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