Re: A little RLS oversight?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Yaroslav <ladayaroslav(at)yandex(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A little RLS oversight?
Date: 2015-07-13 19:01:01
Message-ID: 20150713190100.GD12131@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael,

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Sun, Jul 12, 2015 at 5:59 PM, Yaroslav wrote:
> > I can still see all statistics for 'test' in pg_stats under unprivileged
> > user.
>
> Indeed, this looks like an oversight of RLS. Even if a policy is
> defined to prevent a user from seeing the rows of other users, it is
> still possible to get some information though this view.
> I am adding an open item regarding that for 9.5.

We need to be careful to avoid the slippery slope of trying to prevent
all covert channels, which has been extensively discussed previously. I
tend to agree with this specific case of, if you have RLS configured on
the table then we probably shouldn't allow normal users to see the stats
on the table, but I don't have a problem with the usage of those stats
for generating plans, which users could see the results of via EXPLAIN.

> > I'd prefer statistics on RLS-enabled tables to be simply hidden completely
> > for unprivileged users.
>
> This looks like something simple enough to do.
> @Stephen: perhaps you have some thoughts on the matter? Currently
> pg_stats breaks its promise to only show information about the rows
> current user can read.

I agree that it should be reasonably simple to do and, provided that's
the case, I'm fine with doing it once I get back (currently out until
the 27th).

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Christensen 2015-07-13 20:26:04 [DESIGN] Incremental checksums
Previous Message Andrew Dunstan 2015-07-13 18:56:40 Re: pg_upgrade + Extensions