Re: current_role of caller of a DEFINER function

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

> On Wednesday, June 26, 2024, Dominique Devienne <ddevienne(at)gmail(dot)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 = [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.