Horton

Re: Wrong security context for deferred triggers?

Nico Williams <nico@cryptonector.com>

View thread
From: Nico Williams <nico@cryptonector.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-04-15T16:16:46Z
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().

On Mon, Nov 06, 2023 at 02:23:04PM +0100, Laurenz Albe wrote:
>  SET CONSTRAINTS ALL DEFERRED;

Some years ago I wrote and submitted a patch to allow one to create
constraints that are ALWAYS DEFERRED so that they cannot be made
IMMEDIATE with SET CONSTRAINTS ALL IMMEDIATE.  I do think that one could
use SET CONSTRAINTS ALL ... to defeat [poorly-coded, perhaps] security
measures taken by triggers.

An example of where one might want triggers that are always deferred
would be a ledger application requiring double-entry, where one might
use deferred triggers to check that all debits have matching credits at
commit-time.

Nico
--