From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: has_privs_of_role vs. is_member_of_role, redux |
Date: | 2022-09-25 09:08:10 |
Message-ID: | ed0f732e-bc04-5846-c615-8a85c3fa9812@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas:
> Well, maybe. Suppose that role A has been granted pg_read_all_settings
> WITH INHERIT TRUE, SET TRUE and role B has been granted
> pg_read_all_settings WITH INHERIT TRUE, SET FALSE. A can create a
> table owned by pg_read_all_settings. If A does that, then B can now
> create a trigger on that table and usurp the privileges of
> pg_read_all_settings, after which B can now create any number of
> objects owned by pg_read_all_settings.
I'm not seeing how this is possible. A trigger function would run with
the invoking user's privileges by default, right? So B would have to
create a trigger with a SECURITY DEFINER function, which is owned by
pg_read_all_settings to actually usurp the privileges of that role. But
creating objects with that owner is exactly the thing B can't do.
What am I missing?
Best
Wolfgang
From | Date | Subject | |
---|---|---|---|
Next Message | a.kozhemyakin | 2022-09-25 13:49:27 | Re: tweak to a few index tests to hits ambuildempty() routine. |
Previous Message | Wolfgang Walther | 2022-09-25 08:49:15 | Re: Allow foreign keys to reference a superset of unique columns |