Postgres Pro
Downloads
Home   >   mailing lists

Thread: Before/After Trigger User Switching

Before/After Trigger User Switching

From
"Aasmund Midttun Godal"
Date:
When an operation is done throug a SECURITY DEFINER style function and 
causes a trigger the current_user depends on whether it is executed BEFORE 
or AFTER. I currently run 7.3.2. I believe the BEFORE behavior is correct 
while the AFTER behavior is wrong. A bug? already fixed? 

regards, 

Aasmund. 


CREATE TABLE a (b text); 


CREATE OR REPLACE FUNCTION public.ut () RETURNS TRIGGER SECURITY INVOKER 
LANGUAGE 'plpgsql' AS'     DECLARE      t TEXT;      t2 TEXT;     BEGIN      t := current_user;      t2 :=
session_user;     RAISE NOTICE ''% Current: % Session: %'', TG_WHEN, t, t2;      RETURN NEW;     END
 
'; 

CREATE TRIGGER "ut_trig_before"  BEFORE UPDATE OR INSERT OR DELETE ON a FOR EACH ROW EXECUTE PROCEDURE public.ut(); 

CREATE TRIGGER "ut_trig_after"  AFTER UPDATE OR INSERT OR DELETE ON a FOR EACH ROW EXECUTE PROCEDURE public.ut(); 


CREATE OR REPLACE FUNCTION public.at_test () RETURNS TEXT SECURITY DEFINER 
LANGUAGE 'sql' AS'     INSERT INTO a VALUES (current_user);     SELECT session_user::TEXT || ''/''
||current_user::TEXT;
'; 


db=> SELECT at_test();
NOTICE:  BEFORE Current: godal Session: www
NOTICE:  AFTER Current: www Session: wwwat_test-----------
www/godal
(1 row) 



Aasmund Midttun Godal 

aasmund@godal.com - http://godal.com
+47 40 45 20 46 - Leiv Tronstadsvei 2, NO-7051 Trondheim

Re: Before/After Trigger User Switching

From
"Aasmund Midttun Godal"
Date:
I have upgraded to 7.3.4 and the problem persists. 

Aasmund Midttun Godal writes: 

> When an operation is done throug a SECURITY DEFINER style function and 
> causes a trigger the current_user depends on whether it is executed BEFORE 
> or AFTER. I currently run 7.3.2. I believe the BEFORE behavior is correct 
> while the AFTER behavior is wrong. A bug? already fixed?  
> 
> regards,  
> 
> Aasmund.  
> 
> 
> CREATE TABLE a (b text);  
> 
>  
> 
> CREATE OR REPLACE FUNCTION public.ut () RETURNS TRIGGER SECURITY INVOKER 
> LANGUAGE 'plpgsql' AS'
>      DECLARE
>       t TEXT;
>       t2 TEXT;
>      BEGIN
>       t := current_user;
>       t2 := session_user;
>       RAISE NOTICE ''% Current: % Session: %'', TG_WHEN, t, t2;
>       RETURN NEW;
>      END
> ';  
> 
> CREATE TRIGGER "ut_trig_before"  BEFORE UPDATE OR INSERT OR DELETE
>  ON a FOR EACH ROW EXECUTE PROCEDURE public.ut();  
> 
> CREATE TRIGGER "ut_trig_after"  AFTER UPDATE OR INSERT OR DELETE
>  ON a FOR EACH ROW EXECUTE PROCEDURE public.ut();  
> 
>  
> 
> CREATE OR REPLACE FUNCTION public.at_test () RETURNS TEXT SECURITY DEFINER 
> LANGUAGE 'sql' AS'
>      INSERT INTO a VALUES (current_user);
>      SELECT session_user::TEXT || ''/'' ||current_user::TEXT;
> ';  
> 
>  
> 
> db=> SELECT at_test();
> NOTICE:  BEFORE Current: godal Session: www
> NOTICE:  AFTER Current: www Session: www
> at_test
> -----------
> www/godal
> (1 row)  
> 
>  
> 
> 
> Aasmund Midttun Godal  
> 
> aasmund@godal.com - http://godal.com
> +47 40 45 20 46 - Leiv Tronstadsvei 2, NO-7051 Trondheim 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)


Aasmund Midttun Godal 

aasmund@godal.com - http://godal.com
+47 40 45 20 46 - Leiv Tronstadsvei 2, NO-7051 Trondheim

Re: Before/After Trigger User Switching

From
Tom Lane
Date:
"Aasmund Midttun Godal" <postgresql@aasmund.com> writes:
> When an operation is done throug a SECURITY DEFINER style function and 
> causes a trigger the current_user depends on whether it is executed BEFORE 
> or AFTER. I currently run 7.3.2. I believe the BEFORE behavior is correct 
> while the AFTER behavior is wrong. A bug? already fixed? 

An AFTER trigger is not fired until the interactive statement is about
to complete --- ie, after the SECURITY DEFINER function has returned.
There has been previous discussion (inconclusive) about changing the
time of invocation of AFTER triggers, but given the current timing this
is the behavior I'd expect.
        regards, tom lane

Re: Before/After Trigger User Switching

From
"Aasmund Midttun Godal"
Date:
Thank you for your quick reply! 

I understand your point of view, however the fact remains that you want the 
action to be done as though it was the DEFINER user that did it, and that 
has not changed even thoug the function itself has finished? 

regards, 

aasmund. 


Tom Lane writes: 

> "Aasmund Midttun Godal" <postgresql@aasmund.com> writes:
>> When an operation is done throug a SECURITY DEFINER style function and 
>> causes a trigger the current_user depends on whether it is executed BEFORE 
>> or AFTER. I currently run 7.3.2. I believe the BEFORE behavior is correct 
>> while the AFTER behavior is wrong. A bug? already fixed? 
> 
> An AFTER trigger is not fired until the interactive statement is about
> to complete --- ie, after the SECURITY DEFINER function has returned.
> There has been previous discussion (inconclusive) about changing the
> time of invocation of AFTER triggers, but given the current timing this
> is the behavior I'd expect. 
> 
>             regards, tom lane


Aasmund Midttun Godal 

aasmund@godal.com - http://godal.com
+47 40 45 20 46 - Leiv Tronstadsvei 2, NO-7051 Trondheim

Re: Before/After Trigger User Switching

From
Tom Lane
Date:
"Aasmund Midttun Godal" <postgresql@aasmund.com> writes:
> Thank you for your quick reply! 
> I understand your point of view, however the fact remains that you want the 
> action to be done as though it was the DEFINER user that did it, and that 
> has not changed even thoug the function itself has finished? 

<shrug> ... if there's any bug here, I'd argue that it's that we don't
force trigger functions to run as the owner of the table they're on.
The privileges of the user that did the INSERT or whatever are the wrong
thing in any case, I'd say.

Which suggests a workaround for the moment: your trigger function should
be a SECURITY DEFINER.
        regards, tom lane