Re: RLS Design - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: RLS Design
Date
Msg-id 20140630143122.GJ16098@tamriel.snowman.net
Whole thread Raw
In response to Re: RLS Design  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > I don't see it as really solving the flexibility need and it feels quite
> > a bit more complicated to reason about.  Would someone who is EXEMPT
> > from one policy on a given table still have other policies on that table
> > applied to them?
>
> Yes; otherwise, EXEMPT couldn't be granted by non-superusers, and the
> whole point of that proposal was to come up with something that would
> be clearly safe for ordinary users to use.

I'm confused on this part- granting EXEMPT and/or DIRECT SELECT would
definitely need to be supported by a non-superuser, though someone who
had the appropriate rights on the object involved (either the policy or
the table, depending on where we feel that definition should go).

> > Would a user be able to be EXEMPT from multiple
> > policies?
>
> Yes, clearly.  It would be a privilege on the policy object, so
> different objects can have different privileges.

Ok..  then I'm not entirely sure how this is different from Dean's
proposal except that it's a way of defining the inverse, which we don't
do anywhere else in the system today..

> > I feel like that's what you're suggesting with this approach,
> > otherwise I don't see it as really different from the 'DIRECT SELECT'
> > privilege discussed previously..
>
> Right.  If you took that away, it wouldn't be different.

Ok.

> The number of possible approaches here has expanded beyond what I can
> keep in my head; I'm assuming you are planning to think this over and
> propose something comprehensive, or maybe Dean or someone else will do
> that.  But I'm not sure that all the approaches proposed would make it
> safe for non-superusers to use RLS, and I think it would be good if
> they could.

I've been thinking about it quite a bit over the past few days (weeks?)
and trying to continue to outline the proposals as they've changed.
I'll try and work up another comprehensive email which covers the
options currently under discussion as I understand them.  Allowing
non-superuser to use RLS is absolutely key to this in any case- it'd be
great if you could voice any specific concerns you see there.  We've
already been working through the GUCs previously discussed, as I feel
those will be necessary for any of these approaches (in particular the
"bypass RLS-or-error" GUC which pg_dump will enable by default).
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Robert Haas
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL