Re: Prohibit row-security + inheritance in 9.4?

* Craig Ringer (craig@2ndquadrant.com) wrote:
> 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.

You were argueing that people may be confused by the parent and the
child returning different sets of rows.  I was pointing out that this is
already the case.

> 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.

Right- but you don't see rows from *other* children when querying the
child either.  I was merely trying to point out that we don't make
children and parents be synonyms of each other.  It's not a very strong
argument when it comes to this discussion, but I thought it helped
illustrate that anyone using inheiritance-as-PG-does-it already has a
fair bit of reading to do to be able to understand what's going on.

We also don't have any mechanism to automatically pick the right child
when you insert into the parent either (of course, that can be done with
triggers but that's not automatic :).  Basically, it requires a
non-trivial amount of effort and understanding to use these features.

> > 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.

It makes absolutely zero sense, in my head anyway, to have rows returned
when querying the parent which should NOT be returned based on the quals
of the parent.

> 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.

Good, though I would characterize it as "bug" or "wrong" more than
"ugly". :)

> Since the user can achieve this with:
>
> SELECT ...
> FROM ONLY parent
> UNION ALL
> SELECT ...
> FROM ONLY child1

They could do it with a more complex inheiritance tree also, no?  As in,
with multiple levels or multiple parents where they could redefine the
quals to be used?  Don't think they'd have to resort to views if they
really wanted this (which I tend to doubt many would...).

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

Agreed. :)

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

I do like that. :)

> 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.

Right.

> 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.

Right, let's make sure the documentation lays this out as clearly as we
can make it and perhaps also draw those parallels to how views are
handled with the GRANT system.

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

Excellent. ;)
Thanks,
    Stephen