Horton

Re: Wrong security context for deferred triggers?

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-06-05T15:10:04Z
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().

Noah Misch <noah@leadboat.com> writes:
> 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.

Good point, done.

> 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.

I don't mind s/in the security context of/as/, but not sure if we
need to do more here.  Changing role mid-query seems sufficiently
unusual that we'd probably just confuse people by mentioning the
case.  Unless you have a proposed wording you think is better?

			regards, tom lane