Re: Wrong security context for deferred triggers?

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Wrong security context for deferred triggers?
Дата
Msg-id CAKFQuwYsXRUbTphQeWf6u-ZdwV563nnjTVY1j9FoAS+x1BSQLA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wrong security context for deferred triggers?  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Wrong security context for deferred triggers?
Список pgsql-hackers
Дерево обсуждения
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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema-Nio
Дата:
Сообщение: Re: doc: modify the comment in function libpqrcv_check_conninfo()
Следующее
От: Robert Haas
Дата:
Сообщение: Re: improve predefined roles documentation