Re: document the dangers of granting TRIGGER or REFERENCES - Mailing list pgsql-hackers

From Nico Williams
Subject Re: document the dangers of granting TRIGGER or REFERENCES
Date
Msg-id amad8JQn3Iv0T4++@ubby
Whole thread
In response to document the dangers of granting TRIGGER or REFERENCES  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)
List pgsql-hackers
On Tue, Jul 21, 2026 at 10:06:51AM -0400, Robert Haas wrote:
> On Tue, Jul 21, 2026 at 12:57 AM Nico Williams <nico@cryptonector.com> wrote:
> > Oh, but what I wrote and had in mind is that the TRIGGER _PROCEDURE_
> > would run as the PROCEDURE, though really it should be the TRIGGER
> > owner.  And any functions called by that would run as the same user if
> > they themselves were SECURITY INVOKER.
> 
> Fair enough. I think that still has the problem that I described.

But mainly because of:

> > At least this way anything that the TRIGGER does is done with its
> > owner's permissions.  Though still, as noted, you get a stack of
> > user/role names, starting that of the one that started the top level
> > command.  If you need to do authorization (_you will_) you'll want to
> > know all of those names.
> 
> Knowing all of those names is exactly what I'm working on, but it's a
> much bigger project.

I look forward to that!

At any rate, I agree that this is really not the big deal that reporters
make it out to be.

Nico
-- 



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Recovery conflict resolution misses backends that import snapshots
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Use direct hash lookup in logicalrep_partmap_invalidate_cb()