Date: Tue, 4 Mar 2025 14:01:28 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Ayush Vatsa <ayushvatsa1810@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Clarification on Role Access Rights to Table Indexes
Message-ID: <Z8dcGMMP3-D5dobY@nathan>
References: <CA+TgmobSc_x6thvXZvHoni5Gs5-wsxyTRiOMKoeuX5br0PCtDA@mail.gmail.com>
 <CACX+KaPv4apqG3=Ef+FB9nn4C4cd6Z+604ej0PPOHKExH45u2A@mail.gmail.com>
 <934709.1739829723@sss.pgh.pa.us>
 <CAKFQuwZThU_Z-Zw+3mr+ecp1BVOw777dp3nXU5-wTVk3kS10gw@mail.gmail.com>
 <CA+TgmoZG71zBpLOfCGZqGhtp=88z6=YYhi54TEsCtKr3v+UpoA@mail.gmail.com>
 <1243984.1739894558@sss.pgh.pa.us>
 <CA+Tgmob_W0iq9Kuugra3WYTO2429RMJ_+HkVukrXWOUN81QiEw@mail.gmail.com>
 <1246906.1739896202@sss.pgh.pa.us>
 <CA+TgmoZYM2az+yCWu5DBnV50N_BE9f1r8-Doy6-tZTySeb-s+A@mail.gmail.com>
 <CACX+KaNAbOzePn710EtzH9F5xiUdBC+u59=UMab=Wr8jgDKQtw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACX+KaNAbOzePn710EtzH9F5xiUdBC+u59=UMab=Wr8jgDKQtw@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Z8dcGMMP3-D5dobY%40nathan>
Precedence: bulk

On Wed, Feb 19, 2025 at 03:53:48PM +0530, Ayush Vatsa wrote:
> It seems there's a general consensus that we should maintain a
> original design to support pg_prewarm, with a minor adjustment:
> when querying indexes, we should verify the privileges of the parent table.
> 
> I´ve attached a patch for this, which includes some test cases as well.
> Let me know if it needs any changes.

+        tableOid = IndexGetRelation(relOid, false);
+        aclresult = pg_class_aclcheck(tableOid, GetUserId(), ACL_SELECT);

I'm wondering whether setting missing_ok to true is correct here.  IIUC we
should have an AccessShareLock on the index, but I don't know if that's
enough protection.  The only other similar coding pattern I'm aware of is
RangeVarCallbackForReindexIndex(), which sets missing_ok to false and
attempts to gracefully handle a missing table.  Of course, maybe that's
wrong, too.

Perhaps it's all close enough in practice.  If we get it wrong, you might
get a slightly less helpful error message when the table is concurrently
dropped, which isn't so bad.

-- 
nathan