On 01/07/14 21:51, Robert Haas wrote:
On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
That seems like a pretty strong argument.
If RLS quals are instead regarded as constraints on access, and
multiple policies apply, then it seems that the quals should now be
combined with AND rather than OR, right?
Yeah, maybe. I intuitively feel that OR would be more useful, so it
would be nice to find a design where that makes sense.
Looking at the use cases we described earlier in
http://www.postgresql.org/message-id/attachment/32196/mini-rim.sql I see
more OR than AND, for instance 'if the row is sensitive then the user
must be related to the row' which translates to (NOT sensitive) OR the
user is related.
An addition to that rule could be a breakglass method or other reasons
to access, e.g.
(NOT sensitive) OR user is related OR break glass OR legally required
access.
But it depends
a lot, in my view, on what syntax we end up with. For example,
suppose we add just one command:
ALTER TABLE table_name FILTER [ role_name | PUBLIC ] USING qual;
If the given role inherits from multiple roles that have different
filters, I think the user will naturally expect all of the filters to
be applied.
Suppose a building administrator gives a single person that has multiple
roles multiple key cards to access appropriate rooms in a building. You
could draw a venn diagram of the rooms those key cards open, and the
intuition here probably is that the person can enter any room if one of
the key cards matches, not all cards.
But you could do it other ways. For example:
ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual;
If a table is set to NO ROW LEVEL SECURITY then it behaves just like
it does now: anyone who accesses it sees all the rows, restricted to
those columns for which they have permission. If the table is set to
ROW LEVEL SECURITY then the default is to show no rows. The second
command then allows access to a subset of the rows for a give role
name. In this case, it is probably logical for access to be combined
via OR.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
