Re: has_privs_of_role vs. is_member_of_role, redux

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

In response to

Responses

Browse pgsql-hackers by date

  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