Re: Wrong security context for deferred triggers?

On Thu, Jan 23, 2025 at 07:28:19PM +0100, Laurenz Albe wrote:
> On Thu, 2025-01-23 at 12:30 -0500, Tom Lane wrote:
> > Pushed with some cosmetic adjustments
>
> Thank you!

commit 01463e1 wrote:
> +NOTICE: I am regress_groot

Let's not incur trivially-avoidable trademark risks
(https://google.com/search?q=%22i+am+groot%22) in the source tree.

> --- a/doc/src/sgml/trigger.sgml
> +++ b/doc/src/sgml/trigger.sgml
> @@ -129,6 +129,10 @@
> In all cases, a trigger is executed as part of the same transaction as
> the statement that triggered it, so if either the statement or the
> trigger causes an error, the effects of both will be rolled back.
> + Also, the trigger will always run in the security context of the role
> + that executed the statement that caused the trigger to fire, unless
> + the trigger function is defined as <literal>SECURITY DEFINER</literal>,
> + in which case it will run as the function owner.

Phrase "the role that executed the statement" doesn't match what happens if
the role changes mid-statement. Example of a statement that does so:

select set_config('role', rolname, true), current_user from pg_authid;

The term "security context" doesn't otherwise appear in doc/. I would just
change "run in the security context of the role" to "run as the role". That's
simpler and less likely to create an impression that this stops attacks.