Re: [v9.4] row level security - Mailing list pgsql-hackers

Because of CF-2nd end, it was moved to the next commit-fest.

In my personal opinion, it probably needs a few groundwork to get RLS
commitable,
prior to RLS itself.

One is a correct handling towards the scenario that Korotkov pointed
out. (How was
it concluded?) I think it is a problem we can fix with reasonable way.
Likely, solution
is to prohibit to show number of rows being filtered if plan node is
underlying a sub-
query with security-barrier.

One other stuff I'm concerned about is, existing implementation
assumes a certain
rtable entry performs as a source relation, also result relation in same time on
DELETE and UPDATE.
We usually scan a regular relation to fetch ctid of the tuples to be
modified, then
ModifyTable deletes or updates the tuple being identified. Here has
been no matter
for long period, even if same rtable entry is used to point out a
relation to be scanned
and to be modified.
It however makes RLS implementation complicated, because this feature tries to
replace a rtable entry to relation with row-level security policy by a
simple sub-query
with security-barrier attribute. Our implementation does not assume a sub-query
performs as a result relation, so I had to have some ad-hoc coding,
like adjustment
on varno/varattno of Var objects, to avoid problem.
I think, solution is to separate a rtable entry of result-relation
from rtable entry to
be scanned. It makes easier to implement RLS feature because all we need to do
is just replacement of rtable entry for scanning stage, and no need to
care about
ModifyTable operations towards sub-query.

Is it a right direction to go?

Thanks,

2013/10/10 Marc Munro <marc@bloodnok.com>:
> On Wed, 2013-09-04 at 14:35 +0000, Robert Haas wrote:
>>
>> On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > I think it's entirely sensible to question whether we should reject
>> (not
>> > "hold up") RLS if it has major covert-channel problems.
>>
>> We've already had this argument before, about the security_barrier
> [ . . . ]
>
> Sorry for following up on this so late, I have just been trying to catch
> up with the mailing lists.
>
> I am the developer of Veil, which this thread mentioned a number of
> times.  I wanted to state/confirm a number of things:
>
> Veil is not up to date wrt Postgres versions.  I didn't release a new
> version for 9.2, and when no-one complained I figured no-one other than
> me was using it.  I'll happily update it if anyone wants it.
>
> Veil makes no attempt to avoid covert channels.  It can't.
>
> Veil is a low-level toolset designed for optimising queries about
> privileges.  It allows you to build RLS with reasonable performance, but
> it is not in itself a solution for RLS.
>
> I wish the Postgres RLS project well and look forward to its release in
> Postgres 9.4.
>
> __
> Marc
>
>



-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>