Subject: Re: current_role of caller of a DEFINER function

From: "David G. Johnston" <[email-masked]>
Date: Wed, 26 Jun 2024 05:42:21 -0700

On Wednesday, June 26, 2024, Dominique Devienne <[email-masked]> 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?

David J.

---

From: Isaac Morland <[email-masked]>
Date: Wed, 26 Jun 2024 08:58:17 -0400

> 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 = [calling role] …

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.

---

From: Dominique Devienne <[email-masked]>
Date: Wed, 26 Jun 2024 14:58:44 +0200

> Why can you not use session_user then?

Hi. As I already wrote above, the current_role matters in our security model.
The LOGIN user (i.e. session_user) is used only for authentication to
the DB and to connect.
All other security concerns are on other app-maintained (NOLOGIN)
roles, used for authorization. --DD