Horton

Re: Wrong security context for deferred triggers?

Joseph Koshakow <koshy44@gmail.com>

View thread
From: Joseph Koshakow <koshy44@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-06-09T01:13:07Z
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 Sat, Jun 8, 2024 at 5:36 PM Joseph Koshakow <koshy44@gmail.com> wrote:

>    Additionally, I applied your patch to master and re-ran the example and
>    didn't notice any behavior change.
>
>        test=# CREATE TABLE tab (i integer);
>        CREATE TABLE
>        test=# CREATE FUNCTION trig() RETURNS trigger
>            LANGUAGE plpgsql AS
>         $$BEGIN
>            RAISE NOTICE 'current_user = %', current_user;
>            RETURN NEW;
>         END;$$;
>        CREATE FUNCTION
>        test=# CREATE CONSTRAINT TRIGGER trig AFTER INSERT ON tab
>            DEFERRABLE INITIALLY IMMEDIATE
>            FOR EACH ROW EXECUTE FUNCTION trig();
>        CREATE TRIGGER
>        test=# CREATE ROLE duff;
>        CREATE ROLE
>        test=# GRANT INSERT ON tab TO duff;
>        GRANT
>        test=# SET ROLE duff;
>        SET
>        test=> BEGIN;
>        BEGIN
>        test=*> INSERT INTO tab VALUES (1);
>        NOTICE:  current_user = duff
>        INSERT 0 1
>        test=*> SET CONSTRAINTS ALL DEFERRED;
>        SET CONSTRAINTS
>        test=*> INSERT INTO tab VALUES (2);
>        INSERT 0 1
>        test=*> RESET ROLE;
>        RESET
>        test=*# COMMIT;
>        NOTICE:  current_user = joe
>        COMMIT
>
>    Though maybe I'm just doing something wrong.

Sorry, there's definitely something wrong with my environment. You can
ignore this.

Thanks,
Joe Koshakow