Date: Tue, 15 Apr 2025 08:58:50 -0700
From: Noah Misch <noah@leadboat.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pavel Stehule <pavel.stehule@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Wrong security context for deferred triggers?
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <67338f5d321ae6a4bae646e04b9fe0a1f27dd27c.camel@cybertec.at>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20250415155850.9b.nmisch%40google.com>
Precedence: bulk

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.