Re: RLS Design - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: RLS Design
Date
Msg-id 20140702154254.GH16422@tamriel.snowman.net
Whole thread Raw
In response to Re: RLS Design  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RLS Design  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >> But you could do it other ways.  For example:
> >>
> >> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
> >> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual;
> >>
> >> If a table is set to NO ROW LEVEL SECURITY then it behaves just like
> >> it does now: anyone who accesses it sees all the rows, restricted to
> >> those columns for which they have permission.  If the table is set to
> >> ROW LEVEL SECURITY then the default is to show no rows.  The second
> >> command then allows access to a subset of the rows for a give role
> >> name.  In this case, it is probably logical for access to be combined
> >> via OR.
> >
> > I can see value is having a table-level option to indicate if RLS is
> > applied for that table or not, but I had been thinking we'd just
> > automatically manage that.  That is to say that once you define an RLS
> > policy for a table, we go look and see what policy should be applied in
> > each case.  With the user able to control that, what happens if they say
> > "row security" on the table and there are no policies?  All access would
> > show the table as empty?
>
> I said the same thing in the text you quoted immediately above this reply.

huh.  Somehow I managed to only read the first sentence in that
paragraph.  Clearly I need to go get (more) coffee.  Still- sounds like
agreement. :)

> > What if policies exist and they decide to
> > 'turn off' RLS for the table- suddenly everyone can see all the rows?
>
> That'd be my vote.  Sorta like disabling triggers.

Hmm.  Ok- how would you feel about at least spitting out a WARNING if
there are still policies on the table in that case..?  Just makes me a
bit nervous to have a case where policies can be defined on a table but
are not actually being enforced..

> > Are we getting to a point where there is sufficient agreement that it'd
> > be worthwhile to really start implementing this?
>
> I think we're converging, but it might be a good idea to summarize a
> specific proposal before you start implementing.

Right- will do so later today.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Next
From: Kevin Grittner
Date:
Subject: Re: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.