Re: Prohibit row-security + inheritance in 9.4?

On 2014-01-31 16:05, Stephen Frost wrote:
> * Yeb Havinga (y.t.havinga@mgrid.net) wrote:
>> IMHO, there is another way to implement this, other than the
>> procedure to override the child-rel-quals with the ones from the
>> parent. At DDL time, synchronize quals on the parent with rls quals
>> of the childs. Isn't this also what happens with constraints?
> No, we're not going to do that.  We don't do it for GRANT and I don't
> think it makes sense to do it here.
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.
> 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).

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

What do you mean with 'having the flexibility' and why is that good?
>
>> 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.
>> - 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.

regards,
Yeb Havinga