Re: Prohibit row-security + inheritance in 9.4?

Craig, all,

* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> I'm considering just punting on inheritance for 9.4, adding checks to
> prohibit inheritance from being added to a rel with row security and
> prohibiting any rel with inheritance from being given a row-security policy.

I'm alright with punting on it for 9.4, certainly we need to get the
row-security work done soon if we're going to have any chance of having
this in 9.4 (and I have to admit, I suspect we're pushing the envelope
here already wrt getting row-security into 9.4).

> Earlier discussions seemed to settle on each relation having its own
> row-security quals applied independently. So quals on a parent rel did
> not cascade down to child rels.

This strikes me as a bit odd- isn't this against how we handle the GRANT
system when it comes to inheiritance? That is to say- if you have
access to query the parent, then you'll get rows back from the child and
I believe everyone feels that makes perfect sense.

> That gives you a consistent view of the data in a child rel when
> querying via the parent vs directly, which is good. It's surprising when
> you query via the parent and see rows the parent's row-security
> qualifier doesn't permit, but that surprising behaviour is consistent
> with other surprising things in inheritance, like a primary key on the
> parent not constraining rows inserted into children.

While it agrees with the PK issue, that's a data consistency concern
rather than a security concern, and to contrast this with our existing
security model- if you don't have access to the parent then you can't
query against it; doesn't matter if you have access to the child or not.

> The trouble is that this isn't going to work when applying row-security
> rules using the security barriers support. Security quals get expanded
> before inheritance expansion so that they're copied to all child rels.
> Just what you'd expect when querying a relation that's a parent of an
> inheritance tree via a view.

Right.

> It's what you'd expect to happen when querying a parent rel with
> row-security, too. Parent quals are applied to children. But that then
> gives you an inconsistent view of a rel's contents based on whether you
> query it via a parent or directly.

... Just how our existing GRANT system works.

If you want to constrain the children in the same way as the parent,
then the user can add to the row-security on the children to match the
parent. If the user wants to have one view for the entire inheiritance
tree then they need to only implement the row-security on the parent and
not grant any access for users on the children (or, if they're paranoid,
add row-security to the children which are essentially deny-all).

If we force everything to behave the same between querying the parent
and querying the children then we cut off various scenarios of
partitioning where users are allowed to query specific children but not
the parent or query the parent to get things they're not able to see
directly from the children. This matches the "each rel stands alone"
comment below, from my perspective, but seems to result in a different
behavior from what you describe here. Perhaps that's because "each rel
standing alone", when it comes to inheiritance, looks at the parent as
a simple combination of all the rows from the parent plus the children
and then filtering them based on the row-security of the parent.

> I embarked upon that because of the concern that was expressed here
> about the way KaiGai's row-security patch fiddles directly with
> remapping attributes during planning; rebuilding row-security on top of
> updatable security barrier views was seen as a cleaner approach.

I agree with this approach of adding row-security over top of updatable
security barrier views.

> 1. Prohibit (in CREATE TABLE ... INHERITS, ALTER TABLE ... INHERITS, and
> ALTER TABLE ... SET ROW SECURITY) any parent or child rel from having
> row-security policy, i.e. punt it until 9.5;
>
> 2. Do another round of security qual expansion that fetches quals from
> pg_rowsecurity *after* inheritance expansion, giving us the
> each-relation-stands-alone behaviour;

Again, this doesn't match what I think of as
"each-relation-stands-alone".

> 3. Accept the inconsistent view of child rel contents in exchange for
> the otherwise sane behaviour of applying a parent's quals to children;
> document that if you don't want this, don't grant users direct access to
> the child tables;

Or write identical row-security rules on the children (or deny-all
row-security to force the user to use the parent).

> 4. attempt to pull quals from parents when querying a child rel directly.

That strikes me as borderline insane. ;)

Thanks,

Stephen