Horton

Re: Clarification on Role Access Rights to Table Indexes

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Ayush Vatsa <ayushvatsa1810@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-18T18:16:24Z
Lists: pgsql-hackers, pgsql-general 
On Tue, Feb 18, 2025 at 11:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I have no objection to it, but I wasn't as entirely convinced
> as you are that it's the only plausible answer.

Hmm, OK.

> One specific thing I'm slightly worried about is that a naive
> implementation would probably cause this function to lock the
> table after the index, risking deadlock against queries that
> take the locks in the more conventional order.  I don't recall
> what if anything we've done about that in other places
> (-ENOCAFFEINE).

Yeah, that seems like a good thing to worry about from an
implementation point of view but it doesn't seem like a reason to
question the basic design choice. In general, if you can use a table,
you also get to use its indexes, so that interpretation seems natural
to me here, also. Now, if somebody finds a problem with requiring only
SELECT permission, I could see changing the requirements for both
tables and indexes, but I find it harder to imagine that we'd want
those things to work differently from each other. Of course I'm
willing to be convinced that there's a good reason for them to be
different; I just can't currently imagine what it might be.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.