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
Subject: Re: Wrong security context for deferred triggers?
In-reply-to: <20250415155850.9b.nmisch@google.com>
References: <66021ca9d81c4e1a22b6c417659b05424e130f27.camel@cybertec.at>
 <CAFj8pRB1UVUuEh_T7j7XFo8yYDuEYxoUgMhPXbny6dK1eCvgRg@mail.gmail.com>
 <6bca669972ef0d4a665fa83c5b751ab116324f8f.camel@cybertec.at>
 <CAFj8pRDcy2OaPS7OtceFRhTRq6VKWbdnuawgaX3EXMQVwTR4VA@mail.gmail.com>
 <2653121.1730737337@sss.pgh.pa.us>
 <51386e72c47d922ef68eaa67451a52dc3f569843.camel@cybertec.at>
 <3944969.1737570355@sss.pgh.pa.us>
 <3e4c8fe7adce2e3956e01bae8f1754830bd2d2bf.camel@cybertec.at>
 <201480.1737653448@sss.pgh.pa.us>
 <67338f5d321ae6a4bae646e04b9fe0a1f27dd27c.camel@cybertec.at>
 <20250415155850.9b.nmisch@google.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Tue, 15 Apr 2025 08:58:50 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1283936.1749136204.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 05 Jun 2025 11:10:04 -0400
Message-ID: <1283937.1749136204@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1283937.1749136204%40sss.pgh.pa.us>
Precedence: bulk

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=3D%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 j=
ust
> 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