Re: RLS Design - Mailing list pgsql-hackers

From Robert Haas
Subject Re: RLS Design
Date
Msg-id CA+TgmoZ=ZO+zzYVygPgtpUHuCnwf6inkBHWTqpcUHKeuFmcHtQ@mail.gmail.com
Whole thread Raw
In response to Re: RLS Design  (Stephen Frost <sfrost@snowman.net>)
Responses Re: RLS Design  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sun, Jun 29, 2014 at 3:42 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > An interesting question we haven't much considered is: who can set up
>> > policies and add then to users?  Maybe we should flip this around, and
>> > instead of adding users to policies, we should exempt users from
>> > policies.
>> >
>> > CREATE POLICY p1;
>> >
>> > And then, if they own p1 and t1, they can do:
>> >
>> > ALTER TABLE t1 SET POLICY p1 TO t1_p1_quals;
>> > (or maybe we should associate it to the policy instead of the table:
>> > ALTER POLICY p1 SET TABLE t1 TO t1_p1_quals)
>> >
>> > And then the policy applies to everyone who doesn't have the grantable
>> > EXEMPT privilege on the policy.  The policy owner and superuser have
>> > that privilege by default and it can be handed out to others like
>> > this:
>> >
>> > GRANT EXEMPT ON POLICY p1 TO snowden;
>> >
>> > Then users who have row_level_security=on will bypass RLS if possible,
>> > and otherwise it will be applied.  Users who have
>> > row_level_security=off will bypass RLS if possible, and otherwise
>> > error.  And users who have row_level_security=force will apply RLS
>> > even if they are entitled to bypass it.
>>
>> That's interesting. I need to think some more about what that means.
>
> I'm not a fan of the EXEMPT approach..

Just out of curiosity, why not?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Andres Freund
Date:
Subject: Re: Spinlocks and compiler/memory barriers