Re: has_privs_of_role vs. is_member_of_role, redux

Поиск
Список
Период
Сортировка
От Wolfgang Walther
Тема Re: has_privs_of_role vs. is_member_of_role, redux
Дата
Msg-id ed0f732e-bc04-5846-c615-8a85c3fa9812@technowledgy.de
обсуждение исходный текст
Ответ на Re: has_privs_of_role vs. is_member_of_role, redux  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: has_privs_of_role vs. is_member_of_role, redux
Re: has_privs_of_role vs. is_member_of_role, redux
Список 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 по дате отправления:

Предыдущее
От: Wolfgang Walther
Дата:
Сообщение: Re: Allow foreign keys to reference a superset of unique columns
Следующее
От: a.kozhemyakin@postgrespro.ru
Дата:
Сообщение: Re: tweak to a few index tests to hits ambuildempty() routine.