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 по дате отправления: