Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views
Дата
Msg-id CAEZATCW915=LdN_PaCoMz2ZMq3xMie4UYWRihP5rGo0+yG7y2A@mail.gmail.com
обсуждение исходный текст
Ответ на Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views
Список pgsql-hackers
On Mon, 6 May 2024 at 15:46, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> 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.
>

Hmm, but there are other ways to see how many rows were filtered out:

 - Use pg_stat_get_tuples_returned()
 - Use pg_class.reltuples
 - Use the row estimates from a plain EXPLAIN

and probably more.

Given that this isn't really a security bug, I think EXPLAIN should
probably be left as-is. Otherwise, you'd have to go round closing all
those other "holes" too.

Regards,
Dean



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: [PATCH] Refactor pqformat.{c,h} and protocol.h
Следующее
От: Jeff Davis
Дата:
Сообщение: [18] Policy on IMMUTABLE functions and Unicode updates