Horton

Re: Wrong security context for deferred triggers?

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Joseph Koshakow <koshy44@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-06-26T14:38:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Doc: improve description of which role runs a trigger.

  2. Change role names used in trigger test.

  3. Ensure that AFTER triggers run as the instigating user.

  4. Reverse the search order in afterTriggerAddEvent().

On Wed, Jun 26, 2024 at 2:02 AM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:

>
> I think that we should have some consensus about the following before
> we discuss syntax:
>
> - Does anybody depend on the current behavior and would be hurt if
>   my current patch went in as it is?
>
> - Is this worth changing at all or had we better document the current
>   behavior and leave it as it is?
>
> Concerning the latter, I am hoping for a detailed description of our
> customer's use case some time soon.
>
>
We have a few choices then:
1. Status quo + documentation backpatch
2. Change v18 narrowly + documentation backpatch
3. Backpatch narrowly (one infers the new behavior after reading the
existing documentation)
4. Option 1, plus a new v18 owner-execution mode in lieu of the narrow
change to fix the POLA violation

I've been presenting option 4.

Pondering further, I see now that having the owner-execution mode be the
only way to avoid the POLA violation in deferred triggers isn't great since
many triggers benefit from the implied security of being able to run in the
invoker's execution context - especially if the trigger doesn't do anything
that PUBLIC cannot already do.

So, I'm on board with option 2 at this point.

David J.