Re: Prohibit row-security + inheritance in 9.4?

On 01/31/2014 09:01 AM, Stephen Frost wrote:
> I don't see where this follows at all- clearly, you already get a subset
> of rows from the child than if you queried the parent because there are
> other children.

Er, what? I don't see what you're saying here.

Currently, when you query the parent, you see rows from other children
(superset). You don't ever _not_ see rows from the child that you would
see when querying the child directly.

> If you are first playing with inheritance in PG then it
> might seem odd for that to be the case. Ditto for what you describe
> where the child returns more rows than the parent, but these things need
> to simply be documented as "this is how it works" for those cases where
> both are reasonable possibilities and we need to pick one. 

I'm increasingly inclined to agree. Everything else is too messy, and
creates inflexible limitations for users.

> Personally, I don't see the suggestion that we filter rows accessed via
> the child based on quals of the parent as making any sense.

Neither do I; that (point 4, original post) was pretty much a way to
make the other approaches look better by comparison ;-)

> I feel the
> same about applying child quals when querying through the parent as we
> don't apply GRANT permissions that way. Using the parent and using the
> child are two different paths by which to access the data and which you
> are using is what drives what you will see.

That's a reasonable way to explain it, and consistent with the
privileges model already used for inheritance.

> Is there a case which can't be implemented if the two are independent as
> I am describing?  There are cases which can NOT be implemented if we
> force the two paths to be handled identically but I feel the approach
> where we keep them independently managed is flexible to allow the other
> cases if people want them. 

The only case prevented is one where access to the child via the parent
shows rows that the parent's row-security qual would hide, because the
child's qual doesn't.

Personally I think that's ugly anyway; I don't want to support that, and
have only been looking at it because it'd solve the consistency issues.

Since the user can achieve this with:

SELECT ...
FROM ONLY parent
UNION ALL
SELECT ...
FROM ONLY child1

I think it's fine to just apply the parent qual to all children.

>     There's another bit of fun too: If you have a policy on a child, and
>     query the child via the parent, should the child policy be applied?
> 
> 
> No!  We do not do that for GRANT and I do not see doing it for row
> security either. 

If we're approaching this as "different entry point, different policy",
that makes sense, and I'm increasingly pesuaded by that view of things.

>     Treating row-security checks as permission checks, that'd make this
>     consistent. The difference is that you get a nice error telling you
>     what's going on currently, not a potentially WTF-y different resultset.
> 
> 
> I understand where you're coming from but this strikes me as a
> documentation/definition issue and not really a cause for concern or
> against POLA. These are complex and important topics that anyone who
> cares about security needs to understand. 

I'm happy with that. It's clear that there isn't going to be any way to
do this that doesn't result in _some_ kind of surprising behaviour, so
it's just a matter of being clear about where the astonishment lies.

So what we're talking about here (conveniently, exactly what's currently
impemented) is to:

Apply the policy of the relation actually named in the query before
inheritance expansion. If the relation has children expanded during
planning, allow the parent policy to be copied to those children. The
children are _not_ checked for their own row-security policies when the
appendrel is created, and any child policies are _not_ applied.

That's consistent with how security barrier views (and views in general)
work, and it means that the policy on a relation is applied consistently
to all rows, including rows from child relations. As we discussed, it's
also consistent with relation-level GRANTs for access to relations. The
trade-off is that it creates inconsistent views of the contents of the
data depending on whether you query via a parent, or query a child
directly, and it means that child policies are ignored when querying via
a parent relation.

Since that's what I've already written, I'm happy with that ;-)

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services