Re: Prohibit row-security + inheritance in 9.4?

* Yeb Havinga (yebhavinga@gmail.com) wrote:
> This reasoning could go either way. GRANT is on a complete set of
> rows. This is a restriction on the level of individual rows, and in
> that sense, it is more like a row-level CHECK constraint.

Well, we certainly don't force CHECK constraints on children to apply to
the parent.  If you've got a trigger which is inserting into the child,
that's a different story.

> >If we wanted to make them the same then we'd throw out the ability to do
> >any kind of changes or actions on the child and then we'd have actual
> >partitioning.  We don't have that though, we have inheiritance.
>
> I fail to understand this, probably because I do not have a
> partition use case for inheritance, but rather an information model
> that is more ontology like. The more specific childs get down the
> inheritance tree, more columns they get, and their requirements
> might differ completely in nature from their siblings, and make no
> sense at all as well when specified at the level of the parent (or
> even impossible, since the parent does not have all the columns).

My point here is that you're making an argument for reducing what can be
different between a parent and a child relation if you force
permissions, etc.

> >>Then during expansion of the range table, no code is needed to
> >>ignore child rls quals and copy parent rels to child rels.
> >This is what's already implemented and isn't a huge amount of code to
> >begin with, so I don't see this as being an argument against having the
> >flexibility.
>
> It would seem to me that any additional logic that can be avoided
> during planning is a good thing. Also, the argument that something
> is already implemented, does not itself make it good to commit.

We're already avoiding additional logic by *not* considering the child
relation's quals when it's queried by the parent.

> What do you mean with 'having the flexibility' and why is that good?

The flexibility to allow a user to control access to the child
independently from the access for the parent.

> >>Also, the security policy applied would be invariant to the route
> >>through which the rows were accessed:
> >You could also get this by simply only allowing access to the parent and
> >not granting any privileges on the children.
>
> That might work for partitioning, but not for use cases where childs
> have more columns than parents.

You could still put whatever quals you want on the parent and the child
independently to provide whatever security you want.  The true
inheiritance case makes that more clear, imv, not less- the quals that
you want may not make any sense when applied to the parent as the parent
has fewer columns (perhaps it doesn't have the 'sensitive' columns, for
example).

> >>- directly to the child row: child rls quals and parent quals (by
> >>propagate at ddl) are applied.
> >>- through the parent: child rls quals and parent quals applied.
> >If you want them to be the same then you can implement this yourself
> >without having PG force it on you.
>
> I suggested it as  a solution for a requirement worded upthread as
> "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." without disregarding rls-quals on
> childs.

The point was to disregard the rls-quals on the children.  There are
ways we could make what you're suggesting work but trying to do it with
DDL hacks wouldn't be the right answer anyway- consider what happens
when you're setting up different quals on different children or when
someone goes in and removes the quals on the parent directly.
Thanks,
    Stephen