From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views |
Date: | 2024-07-16 17:36:40 |
Message-ID: | CAEZATCW915=LdN_PaCoMz2ZMq3xMie4UYWRihP5rGo0+yG7y2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 6 May 2024 at 15:46, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2024-07-16 17:42:03 | [18] Policy on IMMUTABLE functions and Unicode updates |
Previous Message | Nathan Bossart | 2024-07-16 17:34:12 | Re: [PATCH] Refactor pqformat.{c,h} and protocol.h |