From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RLS - permissive vs restrictive |
Date: | 2014-10-07 12:10:56 |
Message-ID: | CA+TgmoYZKHqAGXnybZvXqDv82L=TcuBq6r_nUBJnmyxUArx0RA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 7, 2014 at 6:44 AM, Thom Brown <thom(at)linux(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-10-07 12:23:03 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Previous Message | Bruce Momjian | 2014-10-07 12:03:32 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |