Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tk9Bo-000bxv-Im for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2025 22:02:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tk9Bm-003w8u-SK for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2025 22:02:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tk9Bm-003w8m-It for pgsql-hackers@lists.postgresql.org; Mon, 17 Feb 2025 22:02:06 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tk9Bk-001OZA-2j for pgsql-hackers@postgresql.org; Mon, 17 Feb 2025 22:02:05 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 51HM23RM934710; Mon, 17 Feb 2025 17:02:03 -0500 From: Tom Lane To: Ayush Vatsa cc: Robert Haas , "David G. Johnston" , PostgreSQL Hackers Subject: Re: Clarification on Role Access Rights to Table Indexes In-reply-to: References: <855988.1739816850@sss.pgh.pa.us> <861660.1739819589@sss.pgh.pa.us> <908583.1739822263@sss.pgh.pa.us> Comments: In-reply-to Ayush Vatsa message dated "Tue, 18 Feb 2025 03:15:30 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <934708.1739829723.1@sss.pgh.pa.us> Date: Mon, 17 Feb 2025 17:02:03 -0500 Message-ID: <934709.1739829723@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ayush Vatsa 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. Or we could switch to using ownership, which'd keep the code simple but some users might complain it's too restrictive. While I mentioned built-in roles earlier, I now think those mostly carry more privilege than should be required here, given the analogy to SELECT. regards, tom lane