Re: RLS Design

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl>
Subject: Re: RLS Design
Date: 2014-06-30 14:31:22
Message-ID: 20140630143122.GJ16098@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Mon, Jun 30, 2014 at 9:42 AM, Stephen Frost <sfrost(at)snowman(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-30 14:59:22 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Stephen Frost 2014-06-30 14:24:55 Re: pgaudit - an auditing extension for PostgreSQL