Re: Review of Row Level Security

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.

For me, it would help tremendously if you could provide a very
short statement of the over-arching goal of the current development
effort. As an example, I could summarize the SSI development as:

"Ensure that the result of executing any set of successfully
committed serializable transactions is the same as having run those
transactions one at a time, without introducing any new blocking."

Proceeding from a general goal statement like that, to general
principles of how it will be achieved before getting down to
implementation details helps me put the details in proper context.

I apologize again for coming in so late with strong opinions, but I
thought I knew what "row level security" meant, and it was just a
question of how to do it, but I can't reconcile what I thought the
feature was about with the patch I'm seeing; perhaps it's just a
lack of the hight level context  that's making it difficult.

-Kevin

On 22 December 2012 20:13, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:

> I apologize again for coming in so late with strong opinions, but I
> thought I knew what "row level security" meant, and it was just a
> question of how to do it, but I can't reconcile what I thought the
> feature was about with the patch I'm seeing; perhaps it's just a
> lack of the hight level context that's making it difficult.

Agreed, I think we're all feeling that. I'll do my best to accommodate
all viewpoints.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2012/12/22 Kevin Grittner <kgrittn(at)mail(dot)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(at)kaigai(dot)gr(dot)jp>