Message-ID: <4f09548534fa28ee311bc158470496095251fda1.camel@j-davis.com>
Subject: Re: Clarification on Role Access Rights to Table Indexes
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: Mon, 13 Oct 2025 15:11:38 -0700
In-Reply-To: <718744.1760390467@sss.pgh.pa.us>
References: 
	<CACX+KaNAbOzePn710EtzH9F5xiUdBC+u59=UMab=Wr8jgDKQtw@mail.gmail.com>
	 <Z8dcGMMP3-D5dobY@nathan>
	 <CACX+KaO4R9QDxbPSxSB0jNXFsqA6Jf=UPS+tyUvT_YvuP_grVA@mail.gmail.com>
	 <Z8yxsm9ZWVkHlPbV@nathan>
	 <CACX+KaP+6U9jf=GT4wpR7TvRvSMtTAhz=vP2Zr+ZdUFVZzqNsA@mail.gmail.com>
	 <Z8y9RTT-vU6oVI_Y@nathan> <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>
	 <67e077fcfe474ce7c56d36492d89c150768271e1.camel@j-davis.com>
	 <718744.1760390467@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/4f09548534fa28ee311bc158470496095251fda1.camel%40j-davis.com>
Precedence: bulk

On Mon, 2025-10-13 at 17:21 -0400, Tom Lane wrote:
> I don't think so.=C2=A0 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