Horton

Re: Clarification on Role Access Rights to Table Indexes

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
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>
Date: 2025-03-04T20:01:28Z
Lists: pgsql-hackers, pgsql-general 
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

Commits

  1. Fix privilege checks for pg_prewarm() on indexes.

  2. Fix lookup code for REINDEX INDEX.

  3. Fix redefinition of typedef RangeVar.

  4. Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().

  5. dblink: Avoid locking relation before privilege check.