On 07/22/2015 02:17 PM, Dean Rasheed wrote:
> On 21 July 2015 at 04:53, Michael Paquier <michael.paquier@gmail.com> wrote:
>> On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost <sfrost@snowman.net> wrote:
>>> We need to be careful to avoid the slippery slope of trying to prevent
>>> all covert channels, which has been extensively discussed previously.
>
> I think this is more serious than the covert channel leaks discussed
> before, since most_common_vals explicitly reveals values from the
> table, making it an overt leak, albeit of a small portion of the
> table's values.
>
>> Looking at that I am not seeing any straight-forward way to resolve
>> this issue except by hardening pg_stats by having an additional filter
>> of this type so as a non-owner of a relation cannot see the stats of
>> this table directly when RLS is enabled:
>> c.relrowsecurity = false OR c.relowner = current_user::regrole::oid
>> Attached is a patch doing that (/me now hides, expecting to receive
>> laser shots because of the use of current_user on a system view).
>> Thoughts?
>
> Hmm, I think it probably ought to do more, based on whether or not RLS
> is being bypassed or in force-mode -- see the first few checks in
> get_row_security_policies(). Perhaps a new SQL-callable function
> exposing those checks and calling check_enable_rls(). It's probably
> still worth including the "c.relrowsecurity = false" check in SQL to
> save calling the function for the majority of tables that don't have
> RLS.
Please see the attached patch and let me know what you think. I believe
the only thing lacking is documentation for the two new user visible
functions. Comments?
Joe