Re: Blocking execution of SECURITY INVOKER

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Blocking execution of SECURITY INVOKER
Дата
Msg-id 75df9bd9e09b631d66c8a07583ccfe91da359337.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Blocking execution of SECURITY INVOKER  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, 2023-01-12 at 19:38 -0800, Andres Freund wrote:
> I.e. the default arguments where evaluated with the invoker's
> permissions, not
> the definer's, despite being controlled by the less privileged user.

This is a very interesting case. It also involves tricking the
superuser into executing their own function with the attacker's inputs.
That part is the same as the other case. What's intriguing here is that
it shows the function can be SECURITY INVOKER, and that really means it
could be any builtin function as long as the types work out.

For example:
=> create function trick(l pg_lsn = pg_switch_wal()) returns int
language plpgsql security definer as $$ begin return 42; end; $$;

If the superuser executes that, even though it's a SECURITY DEFINER
function owned by an unprivileged user, it will still call
pg_switch_wal().


--
Jeff Davis
PostgreSQL Contributor Team - AWS





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Minimal logical decoding on standbys