MIME-Version: 1.0
References: <CACX+KaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko=D4FSb80BYW+o8CHQ@mail.gmail.com>
 <855988.1739816850@sss.pgh.pa.us> <CAKFQuwZ+EsCJHmBVdHeJ2XUWUBSGtN8k2icrX2hrPR=m7sLNGg@mail.gmail.com>
 <861660.1739819589@sss.pgh.pa.us>
In-Reply-To: <861660.1739819589@sss.pgh.pa.us>
From: Ayush Vatsa <ayushvatsa1810@gmail.com>
Date: Tue, 18 Feb 2025 01:12:44 +0530
Message-ID: <CACX+KaMiZaFWVxYzZ_Lw-EBKgiO5GEBHmHREqs=GDpM88hRqdw@mail.gmail.com>
Subject: Re: Clarification on Role Access Rights to Table Indexes
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000022ee8a062e5bbb2b"
Archived-At: <https://www.postgresql.org/message-id/CACX%2BKaMiZaFWVxYzZ_Lw-EBKgiO5GEBHmHREqs%3DGDpM88hRqdw%40mail.gmail.com>
Precedence: bulk

--00000000000022ee8a062e5bbb2b
Content-Type: text/plain; charset="UTF-8"

> As it stands, a superuser can prewarm an index (because she bypasses all
> privilege checks including this one), but nobody else can.
That's not fully true. Any role can prewarm an index if the role has the
correct privileges.
postgres=# GRANT CREATE ON SCHEMA PUBLIC TO alpha;
GRANT
postgres=# SET ROLE alpha;
SET
postgres=> CREATE TABLE tab(id INT);
CREATE TABLE
postgres=> CREATE INDEX tab_idx ON tab(id);
CREATE INDEX
postgres=> SELECT pg_prewarm('tab_idx');
 pg_prewarm
------------
          1
(1 row)

Don't know what stopped it from prewarming the catalog table index.
Maybe it's checking who is the owner of the table. Although in code
it's just checking the ACL_SELECT [1]. I will be debugging more here
and maybe create a patch for the same.

postgres=# RESET ROLE;
RESET
postgres=# CREATE TABLE superuser_tab(id INT);
CREATE TABLE
postgres=# CREATE INDEX idx_superuser_tab ON superuser_tab(id);
CREATE INDEX
postgres=# GRANT SELECT ON superuser_tab TO alpha;
GRANT
postgres=# SET ROLE alpha;
SET
postgres=> SELECT pg_prewarm('superuser_tab');
 pg_prewarm
------------
          0
(1 row)
postgres=> SELECT pg_prewarm('idx_superuser_tab');
ERROR:  permission denied for index idx_superuser_tab

postgres=> RESET ROLE;
RESET
postgres=# ALTER TABLE superuser_tab OWNER TO alpha;
ALTER TABLE
postgres=# SET ROLE alpha;
SET
postgres=> SELECT pg_prewarm('idx_superuser_tab');
 pg_prewarm
------------
          1
(1 row)

But I agree we should just check the table privileges even in the case of
indexes to decide whether to prewarm or not, as
*indexes don't have any privilegesof their own.*

> I think -hackers would be the appropriate location for that.
I am shifting this to -hackers mailing list instead of general.

[1]
https://github.com/postgres/postgres/blob/master/contrib/pg_prewarm/pg_prewarm.c#L108-L110

Regards,
Ayush Vatsa
SDE AWS

--00000000000022ee8a062e5bbb2b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; As it stands, a superuser can prewarm an index (=
because she bypasses all <br>&gt; privilege checks including this one), but=
 nobody else can.</div><div>That&#39;s not fully true. Any role can prewarm=
 an index if the role has the correct privileges.</div><div>postgres=3D# GR=
ANT CREATE ON SCHEMA PUBLIC TO alpha;</div>GRANT<br>postgres=3D# SET ROLE a=
lpha;<br>SET<br>postgres=3D&gt; CREATE TABLE tab(id INT);<br>CREATE TABLE<b=
r>postgres=3D&gt; CREATE INDEX tab_idx ON tab(id);<br>CREATE INDEX<br>postg=
res=3D&gt; SELECT pg_prewarm(&#39;tab_idx&#39;);<br>=C2=A0pg_prewarm <br>--=
----------<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1<br>(1 row)<div><br></div=
><div>Don&#39;t know what stopped it from prewarming the catalog table inde=
x.</div><div>Maybe it&#39;s checking who is the owner of the table. Althoug=
h in code<br>it&#39;s just checking the ACL_SELECT [1]. I will be debugging=
 more here<br>and maybe create a patch for the same.<br><br></div><div>post=
gres=3D# RESET ROLE;<br>RESET<br>postgres=3D# CREATE TABLE superuser_tab(id=
 INT);<br>CREATE TABLE<br>postgres=3D# CREATE INDEX idx_superuser_tab ON su=
peruser_tab(id);<br>CREATE INDEX<br>postgres=3D# GRANT SELECT ON superuser_=
tab TO alpha;<br>GRANT<br>postgres=3D# SET ROLE alpha;<br>SET<br>postgres=
=3D&gt; SELECT pg_prewarm(&#39;superuser_tab&#39;);<br>=C2=A0pg_prewarm <br=
>------------<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0<br>(1 row)</div><div>=
postgres=3D&gt; SELECT pg_prewarm(&#39;idx_superuser_tab&#39;);<br>ERROR: =
=C2=A0permission denied for index idx_superuser_tab</div><div><br></div><di=
v>postgres=3D&gt; RESET ROLE;<br>RESET<br>postgres=3D# ALTER TABLE superuse=
r_tab OWNER TO alpha;<br>ALTER TABLE<br>postgres=3D# SET ROLE alpha;<br>SET=
<br>postgres=3D&gt; SELECT pg_prewarm(&#39;idx_superuser_tab&#39;);<br>=C2=
=A0pg_prewarm <br>------------<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1<br>(=
1 row)</div><div><br></div><div>But I agree we should just check the table =
privileges even in the case of=C2=A0<br>indexes to decide whether to prewar=
m or not, as <b>indexes don&#39;t have any privileges<br>of their own.</b><=
br><br>&gt; I think -hackers would be the appropriate location for that.<br=
>I am shifting this to -hackers mailing list instead of general.<br><br>[1]=
=C2=A0<a href=3D"https://github.com/postgres/postgres/blob/master/contrib/p=
g_prewarm/pg_prewarm.c#L108-L110">https://github.com/postgres/postgres/blob=
/master/contrib/pg_prewarm/pg_prewarm.c#L108-L110</a><br><br>Regards,<br>Ay=
ush Vatsa<br>SDE AWS</div></div>

--00000000000022ee8a062e5bbb2b--