On Monday, April 28, 2025, Steve Chavez wrote:
>
> 1. Do `grant evtrig_owner to member with inherit false`, then `member`
> will not be able to drop the event trigger.
>
I think they can still use set role…
After getting my head around this, and re-reading what Tom said, I think
you have the gr
Isaac,
> Can somebody remind me why triggers don't run as their owner in the first
place?
> It would make triggers way more useful, and eliminate the whole issue of
trigger owners escalating to whomever tries to access the object on which
the trigger is defined.
Just noted this is already possibl
> You have a bad drop table cleanup command, and I’d drop the entire alter
event trigger owner test.
My bad, removed the bad drop table and also removed the alter owner test.
> The other thing I’m wondering, but haven’t gotten around to testing, is
whether a role affected by the event trigger is
On Tuesday, April 22, 2025, David G. Johnston
wrote:
> On Tuesday, April 22, 2025, David G. Johnston
> wrote:
>
>> On Tuesday, April 22, 2025, Steve Chavez wrote:
>>
>>> > alter event trigger command which doesn’t need to be exercised here
>>>
>>> That part does need to be tested, I modified
>
On Tuesday, April 22, 2025, David G. Johnston
wrote:
> On Tuesday, April 22, 2025, Steve Chavez wrote:
>
>> > alter event trigger command which doesn’t need to be exercised here
>>
>> That part does need to be tested, I modified
>> `AlterEventTriggerOwner_internal` to allow altering owners to r
On Tuesday, April 22, 2025, Steve Chavez wrote:
> > alter event trigger command which doesn’t need to be exercised here
>
> That part does need to be tested, I modified `AlterEventTriggerOwner_internal`
> to allow altering owners to regular users. Before it was only restricted to
> superusers.
>
> alter event trigger command which doesn’t need to be exercised here
That part does need to be tested, I modified
`AlterEventTriggerOwner_internal` to allow altering owners to regular
users. Before it was only restricted to superusers.
> Actually, leave the other member around, but not granted
On Sunday, April 20, 2025, Steve Chavez wrote:
> > Also, this looks unconventional…
> > EventTriggerCacheItem *item = (EventTriggerCacheItem*) lfirst_oid(lc);
>
> Just noticed the mistake there, I would have expected a compilation error.
> New patch attached with the following change:
>
> Event
> Also, this looks unconventional…
> EventTriggerCacheItem *item = (EventTriggerCacheItem*) lfirst_oid(lc);
Just noticed the mistake there, I would have expected a compilation error.
New patch attached with the following change:
EventTriggerCacheItem *item = lfirst(lc);
On Sun, 20 Apr 2025 at
Sorry, attached the output file.
From 2165513e858a5a6c7a620b1499b2f634c4f2ab44 Mon Sep 17 00:00:00 2001
From: steve-chavez
Date: Sun, 20 Apr 2025 19:46:00 -0500
Subject: [PATCH] Allow regular users to create event triggers
---
src/backend/commands/event_trigger.c | 33 +++--
src/bac
On Sunday, April 20, 2025, Steve Chavez wrote:
>
> - A new file event_trigger_nosuper.sql is added for the new tests
>
Expected output for the new script was not included in the commit.
Also, this looks unconventional…
EventTriggerCacheItem *item = (EventTriggerCacheItem*) lfirst_oid(lc);
Da
Hello hackers,
I've now modified my patch to allow regular users (not just database
owners) to create event triggers.
As mentioned by Tom before, this now relies on role membership to allowlist
the target roles of the event trigger.
A summary of the changes:
- EventTriggerCacheItem now has an o
Hi Tom,
> Well, no. That still allows the database owner to commandeer any
> non-superuser role. Even if we tightened "nosuperuser" to mean
> "not superuser and not any built-in role", I don't think it will fly.
Why would the predefined roles be taken into consideration here? The docs
on https:
Steve Chavez writes:
> This is why I thought the database owner is the right role to allow evtrig
> creation since it won't need an explicit list of roles.
> How about requiring explicit non-superuser execution for the database owner
> evtrig? It would be like:
> CREATE EVENT TRIGGER name ... FOR
Many thanks for the feedback.
> an attribute of the trigger and allow both superusers and non-superusers
to create them.
The above is the crux of the issue. Superuser evtrigs can target every role
but non-superusers evtrigs must apply only to a restricted set of roles to
avoid privilege escalatio
On Wed, 5 Mar 2025 at 10:28, Tom Lane wrote:
> I wrote:
> > Or in other words: not-superuser to superuser is far from the only
> > type of privilege escalation that we need to prevent.
>
> After reflecting on that for a moment: maybe say that an event trigger
> fires for queries that are run by a
I wrote:
> Or in other words: not-superuser to superuser is far from the only
> type of privilege escalation that we need to prevent.
After reflecting on that for a moment: maybe say that an event trigger
fires for queries that are run by a role that the trigger's owning
role is a member of? That
Steve Chavez writes:
> Currently PostgreSQL only allows creating event triggers for superusers,
> this prevents usage on PostgreSQL service providers, which do not grant
> superuser access.
> This patch allows database owners to create event triggers, while
> preventing privilege escalation.
I'm
On Wed, Mar 5, 2025 at 7:55 AM Steve Chavez wrote:
> How about requiring explicit non-superuser execution for the database
> owner evtrig? It would be like:
>
> CREATE EVENT TRIGGER name ... FOR NOSUPERUSER;
>
This is more what I was thinking - which works for a boolean. The ability
to have an
Hi,
> Unlike superuser event triggers, which execute functions for every role,
> database owner event triggers are only executed for non-superusers.
Even if we forget about the security aspect for a moment, personally I
have mixed feelings about the idea of adding a new type of event
trigger tha
On Wednesday, March 5, 2025, Aleksander Alekseev
wrote:
>
> > Unlike superuser event triggers, which execute functions for every role,
> database owner event triggers are only executed for non-superusers.
>
All this doesn't strike me as a great UI.
>
Yeah. Seems better to make “execute_for” an a
p 17 00:00:00 2001
From: steve-chavez
Date: Wed, 26 Feb 2025 20:17:36 -0500
Subject: [PATCH] Allow database owners to CREATE EVENT TRIGGER
---
src/backend/commands/dbcommands.c | 22
src/backend/commands/event_trigger.c | 38 --
src/backend/utils/cache/lsyscache.c
22 matches
Mail list logo
