Re: Wrong security context for deferred triggers?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Wrong security context for deferred triggers?
Date: 2025-06-05 15:10:04
Message-ID: 1283937.1749136204@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ken Marshall 2025-06-05 15:14:58 Re: Retiring some encodings?
Previous Message Robert Haas 2025-06-05 14:38:58 Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them