Re: Row security violation error is misleading

* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> On 9 April 2015 at 01:30, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> > That doesn't match what the code currently does:

Ah, right.

> > * Also, allow extensions to add their own policies.
> > *
> > * Note that, as with the internal policies, if multiple policies are
> > * returned then they will be combined into a single expression with
> > * all of them OR'd together. However, to avoid the situation of an
> > * extension granting more access to a table than the internal policies
> > * would allow, the extension's policies are AND'd with the internal
> > * policies. In other words - extensions can only provide further
> > * filtering of the result set (or further reduce the set of records
> > * allowed to be added).
> >
> > which seems reasonable, and means that if there are both internal and
> > external policies, an "allow all" external policy would be a no-op.
>
> Great, I'm glad to see that they're ANDed now.
>
> I wasn't caught up with the current state of this. At some earlier point
> policies from hooks were being ORed, which made mandatory access control
> extensions impossible.

That's what I had been recalling also. I'm certainly on-board with
wanting to support MAC, but I'm wondering what we're going to do when we
add support for "restrictive" policies. We'd certainly want extensions
to be able to provide both kinds and we will need to make sure they are
added correctly, with all of the restrictive policies being combined
and applied together, and then the permissive policies similairly
combined (but with OR's).

Thoughts?

Thanks!

Stephen