2014-07-06 14:19 GMT+09:00 Stephen Frost <sfr...@snowman.net>: > Kaigai, > > * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: >> > Can you clarify where this is coming from..? It sounds like you're >> > referring to an existing implementation and, if so, it'd be good to get >> > more information on how that works exactly. >> >> Oracle VPD - Multiple Policies for Each Table, View, or Synonym >> http://docs.oracle.com/cd/B19306_01/network.102/b14266/apdvpoli.htm#i1008351 >> >> It says - Note that all policies applied to a table are enforced with AND >> syntax. > > While I'm not against using this as an example to consider, it's much > more complex than what we're talking about here- and it supports > application contexts which allow groups of RLS rights to be applied or > not applied; essentially it allows both "AND" and "OR" for sets of RLS > policies, along with "default" policies which are applied no matter > what. > >> Not only Oracle VPD, it fits attitude of defense in depth. >> Please assume a system that installs network firewall, unix permissions >> and selinux. If somebody wants to reference an information asset within >> a file, he has to connect the server from the network address being allowed >> by the firewall configuration AND both of DAC and MAC has to allow his >> access. > > These are not independent systems and your argument would apply to our > GRANT system also, which I hope it's agreed would make it far less > useful. Note also that SELinux brings in another complexity- it needs > to make system calls out to check the access. > >> Usually, we have to pass all the access control to reference the target >> information, not one of the access control stuffs being installed. > > This is true in some cases, and not in others. Only one role you are a > member of needs to have access to a relation, not all of them. There > are other examples of 'OR'-style security policies, this is merely one. > I'm simply not convinced that it applies in the specific case we're > talking about. > > In the end, I expect that either way people will be upset because they > won't be able to specify fully which should be AND vs. which should be > OR with the kind of flexibility other systems provide. What I'm trying > to get to is an initial implementation which is generally useful and is > able to add such support later. > >> > This is similar to how roles work- your overall access includes all access >> > granted to any roles you are a member of. You don't need SELECT rights >> > granted >> > to every role you are a member of to select from the table. Additionally, >> > if an admin wants to AND the quals together then they can simply create >> > a policy which does that rather than have 2 policies. >> > >> It seems to me a pain on database administration, if we have to pay attention >> not to conflict each RLS-policy. > > This notion of 'conflict' doesn't make much sense to me. What is > 'conflicting' here? Each policy would simply need to stand on its own > for the role which it's being applied to. That's very simple and > straight-forward. > >> I expect 90% of RLS-policy will be configured >> to PUBLIC user, to apply everybody same rules on access. In this case, DBA >> has to ensure the target table has no policy or existing policy does not >> conflict with the new policy to be set. >> I don't think it is a good idea to enforce DBA these checks. > > If the DBA only uses PUBLIC then they have to ensure that each policy > they set up for PUBLIC can stand on its own- though, really, I expect if > they go that route they'd end up with just one policy that calls a > stored procedure... > >> > You are suggesting instead that if application 2 sets up policies on the >> > table and then application 1 adds another policy that it should reduce what >> > application 2's users can see? That doesn't make any sense to me. I'd >> > actually expect these applications to at least use different roles anyway, >> > which means they could each have a single role specific policy which only >> > returns what that application is allowed to see. >> > >> I don't think this assumption is reasonable. >> Please expect two applications: app-X that is a database security product >> to apply access control based on remote ip-address of the client for any >> table accesses by any database roles. app-Y that is a usual enterprise >> package for daily business data, with RLS-policy. >> What is the expected behavior in this case? > > That the DBA manage the rights on the tables. I expect that will be > required for quite a while with PG. It's nice to think of these > application products that will manage all access for users by setting up > their own policies, but we have yet to even discuss how they would have > appropriate rights on the table to be able to do so (and to not > interfere with each other..). > > Let's at least get something which is generally useful in. I'm all for > trying to plan out how to get there and would welcome suggestions you > have which are specific to PG on what we could do here (I'm not keen on > just trying to mimic another product completely...), but at the level > we're talking about (either AND them all or OR them all), I don't think > we'd actually solve the use-cases you're describing with either answer. > > Without getting to the full level of having the flexibility to choose > which policies should be AND'd and which should be OR'd, do you see an > issue with adding initial support where each policy has to stand on its > own and then working to address the more complex cases later? > Let me sort out. Probably, the reason of opinion differences come from the point where I and you focus on. It seems to me you try to position the upcoming RLS feature in the context of existing database role and acl mechanism. I think it is a straightforward approach and never argue. On the other hand, I'm worrying about whether we can utilize the RLS feature as a basis to implement different security model that performs independently from database roles and acl.
As long as RLS-policy quals are connected with OR, it is a design choice to fit behavior of database acl and grant / revoke. Things I'd like you to pay attention is, how much flexible to use this RLS feature as a basis of other security model. One candidate is selinux; that does not pay attention on database roles, so row-level security policy attached by selinux should not be over-written by database roles. As you mentioned above, RLS-policy is connected with user-given quals by AND'd manner, like: SELECT * FROM t1 WHERE x like '%abc%'; being replaced to SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS); What I'd like to implement is adjustment of query like: SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS) AND (quals by extension-1) AND ... AND (quals by extension-N); I never mind even if qualifiers in the second block are connected with OR'd manner, however, I want RLS infrastructure to accept additional security models provided by extensions. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers