Re: RLS - permissive vs restrictive - Mailing list pgsql-hackers

From Robert Haas
Subject Re: RLS - permissive vs restrictive
Date
Msg-id CA+TgmoYZKHqAGXnybZvXqDv82L=TcuBq6r_nUBJnmyxUArx0RA@mail.gmail.com
Whole thread Raw
In response to RLS - permissive vs restrictive  (Thom Brown <thom@linux.com>)
Responses Re: RLS - permissive vs restrictive
List pgsql-hackers
On Tue, Oct 7, 2014 at 6:44 AM, Thom Brown <thom@linux.com> wrote:
> It appears that I'm not the only person who finds it somewhat
> unintuitive for overlapping RLS policies to be permissive rather than
> restrictive (OR vs AND) (at least 3 others seem to expect AND
> behaviour), although I understand the reasoning behind
> it.  And I've since discovered that the same feature in another
> database system uses the latter rather than the former.
>
> I posted a brain coredump of my thoughts on the matter on Depesz's
> blog (http://www.depesz.com/2014/10/02/waiting-for-9-5-row-level-security-policies-rls/#comment-187800)
> and I was wondering if there's a future in allowing both systems.  The
> syntax is less important than the functionality, where restrictive
> policies would be AND'd, permissive policies would (like they
> currently do) be OR'd, and a combination would involve all restrictive
> plus at least one permissive (i.e. restr1 AND restr2 AND (perm3 OR
> perm4)).
>
> I'm just interested to know what others' thoughts on the matter are.

I think that could make sense.  I think the main thing to consider is
the case where different policies apply to different users: what will
be the combined effect for users who are subjected to any subset of
those policies?   If the same policies applies to everyone, then you
can just do it all as a single policy and put whatever Boolean logic
you like inside of it.

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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Next
From: Simon Riggs
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}