Re: PG 18 release notes draft committed

On Tue, Jun 3, 2025 at 10:21:23AM -0700, Noah Misch wrote:
> On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> > I have committd the first draft of the PG 18 release notes.
>
> When a commit changes the user that runs a function in existing queries, I
> think that almost always needs a release notes entry. It would follow that
> commit 01463e1 needs an entry. I recommend text "Run each deferred trigger as
> the role that caused the trigger to fire."

Okay, let's look at the commit:

commit 01463e1cccd
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Thu Jan 23 12:25:45 2025 -0500

Ensure that AFTER triggers run as the instigating user.

With deferred triggers, it is possible that the current role changes
between the time when the trigger is queued and the time it is
executed (for example, the triggering data modification could have
been executed in a SECURITY DEFINER function).

Up to now, deferred trigger functions would run with the current role
set to whatever was active at commit time. That does not matter for
foreign-key constraints, whose correctness doesn't depend on the
current role. But for user-written triggers, the current role
certainly can matter.

Hence, fix things so that AFTER triggers are fired under the role
that was active when they were queued, matching the behavior of
BEFORE triggers which would have actually fired at that time.
(If the trigger function is marked SECURITY DEFINER, that of course
overrides this, as it always has.)

This does not create any new security exposure: if you do DML on a
table owned by a hostile user, that user has always had various ways
to exploit your permissions, such as the aforementioned BEFORE
triggers, default expressions, etc. It might remove some security
exposure, because the old behavior could potentially expose some
other role besides the one directly modifying the table.

There was discussion of making a larger change, such as running as
the trigger's owner. However, that would break the common idiom of
capturing the value of CURRENT_USER in a trigger for auditing/logging
purposes. This change will make no difference in the typical scenario
where the current role doesn't change before commit.

Arguably this is a bug fix, but it seems too big a semantic change
to consider for back-patching.

Author: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Reviewed-by: Joseph Koshakow <koshy44(at)gmail(dot)com>
Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Discussion: https://postgr.es/m/77ee784cf248e842f74588418f55c2931e47bd78.camel@cybertec.at

There are two questions --- should it be mentioned in the release notes,
and should it be listed in the incompatibility section.

It is called a bug fix, which I think means it is just implementing a
behavior that users already expected. (Yes, there is a doc addition to
clarify this.) I thought it was an edge case that didn't warrant
mention in the release notes, and the rare cases would be caught in
application testing.

Now, if we do want to mention it, it should be done in a way that makes
it clear to readers whether they are affected by this change. We can
try text like:

Execute non-SECURITY-DEFINER AFTER triggers as the role that was
active at the time the trigger was fired

Previously such triggers were run as the role that was active at
commit time.

Seems like this would be in the incompatibility section, if we want to
add it.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.