Isaac,
> Can somebody remind me why triggers don't run as their owner in the first place?
> It would make triggers way more useful, and eliminate the whole issue of trigger owners escalating to whomever tries to access the object on which the trigger is defined.
Just noted this is already possible when marking the event trigger function as SECURITY DEFINER (instead of having the SECURITY INVOKER default), it will fire for every role but keeping the privilege of the event trigger creator.
Seeing that we have a problem with membership-based event triggers, how about if we require that regular user event triggers can only have SECURITY DEFINER functions? We can enforce this at `create event trigger` time.
Best regards,
Steve Chavez
I wrote:
> Or in other words: not-superuser to superuser is far from the only
> type of privilege escalation that we need to prevent.
After reflecting on that for a moment: maybe say that an event trigger
fires for queries that are run by a role that the trigger's owning
role is a member of? That changes nothing for superuser-owned
triggers.
Can somebody remind me why triggers don't run as their owner in the first place?
It would make triggers way more useful, and eliminate the whole issue of trigger owners escalating to whomever tries to access the object on which the trigger is defined.
