Re: Review of Row Level Security - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: Review of Row Level Security
Date
Msg-id CADyhKSWs1EDPA5yxe2UbPcPC2S6WYXpTK6ZHHwX3piQ3RjC=Cw@mail.gmail.com
Whole thread Raw
In response to Re: Review of Row Level Security  ("Kevin Grittner" <kgrittn@mail.com>)
List pgsql-hackers
2012/12/22 Kevin Grittner <kgrittn@mail.com>:
> Kohei KaiGai wrote:
>
>> RLS entry of wiki has not been updated for long time, I'll try to
>> update the entry for high-level design in a couple of days.
>
> Thanks, I think that is essential for a productive discussion of
> the issue.
>
I tried to update http://wiki.postgresql.org/wiki/RLS

I backed to the definition of feature for information security; that
requires to ensure confidentiality, integrity and availability (C.I.A)
of information asset managed by system.
Access control contributes the first two elements.
So, I'm inclined RLS feature "eventually" support reader-side and
writer-side, to prevent unprivileged rows are read or written.

If I could introduce the most conceptual stuff in one statement,
it shall be:
"Overall, RLS prevents users to read and write rows that does not
satisfies the row-security policy being configured on the table by
the table owner. Reader-side ensures confidentiality of data,
writer-side ensures integrity of data."
Also note that, I believe this criteria never deny to have multiple
(asymmetric) row-security policy for each command type, as long
as we care about problematic scenario properly.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: buffer assertion tripping under repeat pgbench load
Next
From: Simon Riggs
Date:
Subject: Re: Review of Row Level Security