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