Re: Wrong security context for deferred triggers?

On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> Like you, I was surprised by the current behavior. There is a design
> principle that PostgreSQL tries to follow, called the "Principle of
> least astonishment". Things should behave like a moderately skilled
> user would expect them to. In my opinion, the current behavior
violates
> that principle. Tomas seems to agree with that point of view.

I worry that both approaches violate this principle in different ways.
For example consider the following sequence of events:

SET ROLE r1;
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
INSERT INTO ...;
SET ROLE r2;
SET search_path = '...';
COMMIT;

I think that it would be reasonable to expect that the triggers execute
with r2 and not r1, since the triggers were explicitly deferred and the
role was explicitly set. It would likely be surprising that the search
path was updated for the trigger but not the role. With your proposed
approach it would be impossible for someone to trigger a trigger with
one role and execute it with another, if that's a desirable feature.

> I didn't find this strange behavior myself: it was one of our customers
> who uses security definer functions for data modifications and has
> problems with the current behavior, and I am trying to improve the
> situation on their behalf.

Would it be possible to share more details about this use case? For
example, What are their current problems? Are they not able to set
constraints to immediate? Or can they update the trigger function
itself be a security definer function? That might help illuminate why
the current behavior is wrong.

> But I feel that the database user that runs the trigger should be the
> same user that ran the triggering SQL statement. Even though I cannot
> put my hand on a case where changing this user would constitute a real
> security problem, it feels wrong.
>
> I am aware that that is rather squishy argumentation, but I have no
> better one. Both my and Thomas' gut reaction seems to have been "the
> current behavior is wrong".

I understand the gut reaction, and I even have the same gut reaction,
but since we would be treating roles exceptionally compared to the rest
of the execution context, I would feel better if we had a more concrete
reason.

I also took a look at the code. It doesn't apply cleanly to master, so
I took the liberty of rebasing and attaching it.

> + /*
> + * The role could have been dropped since the trigger was queued.
> + * In that case, give up and error out.
> + */
> + pfree(GetUserNameFromId(evtshared->ats_rolid, false));

It feels a bit wasteful to allocate and copy the role name when we
never actually use it. Is it possible to check that the role exists
without copying the name?

Everything else looked good, and the code does what it says it will.

Thanks,
Joe Koshakow