Horton

Re: Wrong security context for deferred triggers?

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Joseph Koshakow <koshy44@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-06-26T15:53:02Z
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, 2024-06-26 at 07:38 -0700, David G. Johnston wrote:
> 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.

Nice.

I think we can safely rule out option 3.
Even if it is a bug, it is not one that has bothered anybody so far that a backpatch
is indicated.

Yours,
Laurenz Albe