Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views
Дата
Msg-id 3a60be45e7a89f50d166dba49553950d6b8a97f5.camel@cybertec.at
обсуждение исходный текст
Ответы Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
Currently, it is pretty easy to subvert the restrictions imposed
by row-level security and security_barrier views.  All you have to
to is use EXPLAIN (ANALYZE) and see how many rows were filtered
out by the RLS policy or the view condition.

This is not considered a security bug (I asked), but I still think
it should be fixed.

My idea is to forbid EXPLAIN (ANALYZE) for ordinary users whenever
a statement uses either of these features.  But restricting it to
superusers would be too restrictive (with a superuser, you can never
observe RLS, since superusers are exempt) and it would also be
dangerous (you shouldn't perform DML on untrusted tables as superuser).

So I thought we could restrict the use of EXPLAIN (ANALYZE) in these
situations to the members of a predefined role.  That could be a new
predefined role, but I think it might as well be "pg_read_all_stats",
since that role allows you to view sensitive data like the MCV in
pg_statistic, and EXPLAIN (ANALYZE) can be seen as provideing executor
statistics.

Attached is a POC patch that implements that (documentation and
regression tests are still missing) to form a basis for a discussion.

There are a few things I would like feedback about:

- is it OK to use "pg_read_all_stats" for that?

- should the check be moved to standard_ExplainOneQuery()?

Yours,
Laurenz Albe

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Removing unneeded self joins