| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Joseph Koshakow <koshy44(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Wrong security context for deferred triggers? |
| Date: | 2024-06-26 15:53:02 |
| Message-ID: | fa0124428f6715143ba01ee669b0591dfe958817.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-06-26 16:11:45 | Re: Reg: Alternate way of hashing database role passwords |
| Previous Message | Nathan Bossart | 2024-06-26 15:48:30 | Re: improve predefined roles documentation |