Thread: error in trigger creation

so that it will be able to assign the privilege, so we will be able to create the event trigger without need to run the event trigger script from super user itself?

On Sun, Apr 21, 2024 at 1:55 PM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Sunday, April 21, 2024, yudhi s <learnerdatabase99@gmail.com> wrote:

so that it will be able to assign the privilege, so we will be able to create the event trigger without need to run the event trigger script from super user itself?

Write a security-definer function owned by superuser and grant app_user permission to execute it.

David J.

 

Thank You David.

 Are you saying something like below, in which we first create the function from super user and then execute the grant? But doesn't that mean, each time we want to create a new event trigger we have to be again dependent on the "super user" to modify the security definer function?

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sunday, April 21, 2024, yudhi s <learnerdatabase99@gmail.com> wrote:
>> Are you saying something like below, in which we first create the
>> function from super user and then execute the grant? But doesn't that mean,
>> each time we want to create a new event trigger we have to be again
>> dependent on the "super user" to modify the security definer function?

> Dynamic SQL.  See “execute” in plpgsql.

You might as well just give that user superuser and be done with it.
It's foolish to imagine that you have any shred of security left
if you're letting a user that's not 100.00% trusted write event
triggers.  (Much less execute any SQL command whatsoever, which
is what it sounds like David is suggesting you create a function
to do.)

            regards, tom lane

On 4/21/24 11:20, yudhi s wrote:
> 
> On Sun, Apr 21, 2024 at 8:13 PM Tom Lane <tgl@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
> 

> 
> So do you mean , we should not create the event trigger using the 
> "security definer" , rather have the super user do this each time we 
> have to create the event trigger?
> 
> Actually , I am not very much aware about the security part, but is it 
> fine to give the super user privilege to the application user(say 
> app_user) from which normally scripts/procedures get executed by the 
> application, but nobody(individual person) can login using that user.
> 
> Additionally in other databases, triggers are driven by some 
> specific privileges (say for example in oracle "create trigger" 
> privilege). And it doesn't need any super user and we were having many 

Which Postgres has

    https://www.postgresql.org/docs/current/ddl-priv.html

    TRIGGER

             Allows creation of a trigger on a table, view, etc.


but you are talking about event triggers

    https://www.postgresql.org/docs/current/sql-createeventtrigger.html

where

    "Only superusers can create event triggers."

To paraphrase Henry Ford, you can have any user for an event trigger as 
long as the user is a superuser.



> applications in which the application user (which were used for app to 
> app login) was having these privileges, similar to "create table" 
> privileges which comes by default to the schema who owns the objects  
> etc. So in this case i was wondering if "event trigger" can cause any 
> additional threat and thus there is no such privilege like "create 
> trigger" exist in postgres and so it should be treated cautiously?

An event trigger runs as a superuser and executes a function that in 
turn can do many things, you do the math on the threat level.


-- 
Adrian Klaver
adrian.klaver@aklaver.com

Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 4/21/24 11:20, yudhi s wrote:
>> So in this case i was wondering if "event trigger" can cause any 
>> additional threat and thus there is no such privilege like "create 
>> trigger" exist in postgres and so it should be treated cautiously?

> An event trigger runs as a superuser and executes a function that in 
> turn can do many things, you do the math on the threat level.

As a trivial example: an event trigger could prevent the legitimate
superuser(s) from doing anything at all in that database, just by
blocking all their commands.  This might not even require malicious
intent, merely faulty coding --- but the opportunity for malicious
intent is staggeringly large.

            regards, tom lane

On 4/21/24 14:21, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 4/21/24 11:20, yudhi s wrote:
>>> So in this case i was wondering if "event trigger" can cause any
>>> additional threat and thus there is no such privilege like "create
>>> trigger" exist in postgres and so it should be treated cautiously?
> 
>> An event trigger runs as a superuser and executes a function that in
>> turn can do many things, you do the math on the threat level.
> 
> As a trivial example: an event trigger could prevent the legitimate
> superuser(s) from doing anything at all in that database, just by
> blocking all their commands.  This might not even require malicious
> intent, merely faulty coding --- but the opportunity for malicious
> intent is staggeringly large.

As an FYI to above:

https://www.postgresql.org/docs/current/sql-createeventtrigger.html

"Event triggers are disabled in single-user mode (see postgres). If an 
erroneous event trigger disables the database so much that you can't 
even drop the trigger, restart in single-user mode and you'll be able to 
do that."


> 
>             regards, tom lane

-- 
Adrian Klaver
adrian.klaver@aklaver.com