Re: RLS Design - Mailing list pgsql-hackers

Kaigai,

* Kouhei Kaigai (kaigai@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?
Thanks,
    Stephen