MIME-Version: 1.0
References: <CAFCRh--0j77ueun+Ak0vRe_vi__Jks_HZjD9QbD+THR8gAWvRQ@mail.gmail.com>
 <CAKFQuwbnK-gEL=LrtMpkvGGSHCdwhSvDgcJCu6QNj-6rquGRtQ@mail.gmail.com>
In-Reply-To: <CAKFQuwbnK-gEL=LrtMpkvGGSHCdwhSvDgcJCu6QNj-6rquGRtQ@mail.gmail.com>
From: Isaac Morland <isaac.morland@gmail.com>
Date: Wed, 26 Jun 2024 08:58:17 -0400
Message-ID: <CAMsGm5fKf=-WiEOd0T62HxV+85WNYd_y4hi4XXPO8cDG0USk9Q@mail.gmail.com>
Subject: Re: current_role of caller of a DEFINER function
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Dominique Devienne <ddevienne@gmail.com>, 
	"pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000025f40f061bca9293"
Archived-At: <https://www.postgresql.org/message-id/CAMsGm5fKf%3D-WiEOd0T62HxV%2B85WNYd_y4hi4XXPO8cDG0USk9Q%40mail.gmail.com>
Precedence: bulk

--00000000000025f40f061bca9293
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 26 Jun 2024 at 08:42, David G. Johnston <david.g.johnston@gmail.com=
>
wrote:

> On Wednesday, June 26, 2024, Dominique Devienne <ddevienne@gmail.com>
> wrote:
>
>> Only session_user
>> is representative of the caller, and reliable (modulo SUPERUSER and
>> SET AUTHORIZATION, but that's a different story and kinda normal)
>>
>
> Why can you not use session_user then?
>

Speaking only for myself, if I am writing a security definer and I go to
check the calling role, I want to know the role which was used in the
privilege check as to whether the function would even be permitted to be
called. What I would be looking for is to behave differently depending on
who called me. The original role which connected to the database is totally
irrelevant, and could even be a security problem: if superuser does a set
role, I shouldn't then be doing security checks which report back that the
current role is superuser.

Imagine code like this:

select objects from table where owner =3D [calling role] =E2=80=A6

I think this ties into the related discussions on questions like what
search_path should be in effect during trigger execution and during REFRESH
MATERIALIZED VIEW and other maintenance commands. It also relates into the
question of what role executes triggers and performs calculations during
REFRESH MATERIALIZED VIEW and other maintenance commands.

Essentially the current behaviour is quirky and built up over time by a
series of individual decisions, and does not appear to have any systematic
theory of operation which would answer all these questions all at once.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, 26 Jun 2024 at 08:42, David G. Jo=
hnston &lt;<a href=3D"mailto:david.g.johnston@gmail.com">david.g.johnston@g=
mail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
">On Wednesday, June 26, 2024, Dominique Devienne &lt;<a href=3D"mailto:dde=
vienne@gmail.com" target=3D"_blank">ddevienne@gmail.com</a>&gt; wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">Only session_user<br>
is representative of the caller, and reliable (modulo SUPERUSER and<br>
SET AUTHORIZATION, but that&#39;s a different story and kinda normal)<br>
</blockquote><div><br></div><div>Why can you not use session_user then?</di=
v></blockquote><div><br></div><div>Speaking only for myself, if I am writin=
g a security definer and I go to check the calling role, I want to know the=
 role which was used in the privilege check as to whether the function woul=
d even be permitted to be called. What I would be looking for is to behave =
differently depending on who called me. The original role which connected t=
o the database is totally irrelevant, and could even be a security problem:=
 if superuser does a set role, I shouldn&#39;t then be doing security check=
s which report back that the current role is superuser.</div><div><br></div=
><div>Imagine code like this:</div><div><br></div><div>select objects from =
table where owner =3D [calling role] =E2=80=A6</div><div><br></div><div>I t=
hink this ties into the related discussions on questions like what search_p=
ath should be in effect during trigger execution and during REFRESH MATERIA=
LIZED VIEW and other maintenance commands. It also relates into the questio=
n of what role executes triggers=C2=A0and performs calculations during REFR=
ESH MATERIALIZED VIEW and other maintenance commands.</div><div><br></div><=
div>Essentially the current behaviour is quirky and built up over time by a=
 series of individual decisions, and does not appear to have any systematic=
 theory of operation which would answer all these questions all at once.</d=
iv></div></div>

--00000000000025f40f061bca9293--