Re: Clarification on Role Access Rights to Table Indexes

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> 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.

Robert might remember better, but I think the assumption behind
the current design of RangeVarGetRelidExtended is that it's not
okay to take a lock in the first place if you don't have the
privilege to do so. Your analysis here supposes that it's okay
to take a lock without privileges so long as you can't block someone
else for very long, where "very long" is not tightly defined but
hopefully isn't controllable by the malicious user. So that's
moving the goalposts somewhat, but you might get people to sign
onto it with more careful analysis of the worst-case delay.
(The thing I'd worry about is whether it's possible to block
execution of the privilege check, or even just make it slow.)

Given that definition, I think you're right that it's possible to
identify cases where lock-then-check can't cause meaningful DoS.
RangeVarGetRelidExtended has to cope with the general case, so
that's not an argument for simplifying it, but we might not need
equivalent complexity everywhere.

regards, tom lane