Re: has_privs_of_role vs. is_member_of_role, redux - Mailing list pgsql-hackers

From Wolfgang Walther
Subject Re: has_privs_of_role vs. is_member_of_role, redux
Date
Msg-id ed0f732e-bc04-5846-c615-8a85c3fa9812@technowledgy.de
Whole thread Raw
In response to Re: has_privs_of_role vs. is_member_of_role, redux  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: has_privs_of_role vs. is_member_of_role, redux
Re: has_privs_of_role vs. is_member_of_role, redux
List 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



pgsql-hackers by date:

Previous
From: Wolfgang Walther
Date:
Subject: Re: Allow foreign keys to reference a superset of unique columns
Next
From: a.kozhemyakin@postgrespro.ru
Date:
Subject: Re: tweak to a few index tests to hits ambuildempty() routine.