Re: Clarification on Role Access Rights to Table Indexes

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clarification on Role Access Rights to Table Indexes
Date: 2025-02-17 22:17:26
Message-ID: CAKFQuwZThU_Z-Zw+3mr+ecp1BVOw777dp3nXU5-wTVk3kS10gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Feb 17, 2025 at 3:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com> writes:
> > Thanks Robert for confirming, let me submit a patch to fix the same.
>
> Well, the first thing you need is consensus on what the behavior
> should be instead.
>
> I have a very vague recollection that we concluded that SELECT
> privilege was a reasonable check because if you have that you
> could manually prewarm by reading the table. That would lead
> to the conclusion that the minimal fix is to look at the owning
> table's privileges instead of the index's own privileges.
>

I feel like if you can blow up the cache by loading an entire table into
memory with just select privilege on the table we should be ok with
allowing the same person to name an index on the same table and load it
into the cache too.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2025-02-17 23:03:18 Re: Loading the latest N rows into the cache seems way too fast.
Previous Message Tom Lane 2025-02-17 22:02:03 Re: Clarification on Role Access Rights to Table Indexes

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-02-17 22:33:03 Re: Adding NetBSD and OpenBSD to Postgres CI
Previous Message Ilia Evdokimov 2025-02-17 22:13:34 Re: describe special values in GUC descriptions more consistently