Horton

Re: Clarification on Role Access Rights to Table Indexes

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 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-14T17:01:37Z
Lists: pgsql-hackers, pgsql-general 
On Tue, 2025-10-14 at 11:05 -0500, Nathan Bossart wrote:
> For
> pg_prewarm, I don't know.  You do have to install the extension
> before
> using it, but once installed, it's available to everyone by default. 
> My
> guess is that it just hasn't been a problem in the field.

If we start with an OID, what's the right way to do these kinds of
checks? Could we do an ACL check, then lock it, then do an ACL check
again to catch OID wraparound?

Last-minute suggestions on 0003:

  * Add a comment around the privOid check to explain that, if the
object is an index, we must check the privileges on the table instead.

  * Clarify in the comment that the race against index drop/recreation
involves OID wraparound.

+1 to the patch and backpatch.

As a separate thought, I'm wondering if we should do more to enforce
the idea that we check the privileges and owner of an index's table,
and never the index itself. That's for another discussion, though.

> Regardless, fixing the lock-before-privilege-checks behavior doesn't
> strike
> me as a bug, so I think we ought to proceed with something like 0003
> for
> back-patching purposes and then to rework it further for v19.  Does
> that
> sound okay to you?

According to the current rules[1], it does seem to technically be a
bug, but as far as I can tell, not one of much consequence.

Regards,
	Jeff Davis

[1]
https://www.postgresql.org/message-id/976405.1760459426@sss.pgh.pa.us

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.