On Wed, 26 Jun 2024 at 08:42, David G. Johnston <david.g.johns...@gmail.com> wrote:
> On Wednesday, June 26, 2024, Dominique Devienne <ddevie...@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 = [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.
