Re: security label support, part.2

(2010/08/16 22:14), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> The purpose of this restriction is to ensure an access control decision
>> using parent's label being also consistent on child tables.
>
> Robert and I understand the concern that you have. The answer, at least
> for now, is that we don't agree with you. PG doesn't consider child
> tables to be independent objects when they're being accessed through the
> parent. As such, they don't have their own permissions checking.
>
>> If we control accesses on child tables using child's label, no need to
>> restrict an identical label within an entire inheritance hierarchy.
>> But it needs to provide the original rte->requiredPerms of child tables.
>> Now it is cleared at expand_inherited_rtentry(), so we have no way to
>> control accesses on child tables using child's label. :(
>
> If you want to argue that we should care about the childs permissions,
> or do something different with regard to inheritance, then you need to
> make that argument for all of PG, not just try to do what you think is
> right in the security definer framework.
>
>> > From viewpoint of MAC, both of the following SQLs should be denied,
>> when accesses on parent_tbl is allowed, but child_tbl is denied.
>
> KaiGai, this is not a MAC vs. DAC difference. This is a question of
> "what is an object" and if a child table is really an independent object
> from a parent table. In PG, we've decided they're not. We should
> probably do more to make that clearer in PG, rather than have different
> parts of the system treat them differently.
>
Ahh, yes, the question is "what is an object", not a "MAC vs DAC".

Indeed, PG does not try to handle child table as an independent object
from a parent table. However, if so, it seems to me strange that we can
assign individual ownership and access privileges on child tables.

If we stand on the perspective that child tables are a part of the
parent table, isn't it necessary to keep same ownership and access
privileges between parent and children? It seems to me the current
implementation is in the halfway from the perspective of child
tables as independent object to the perspective of child tables as
a part of parent table.

If PG can keep consistency of ownership and access privileges between
parent and children, it is quite natural we keep consistency of labels,
isn't it?

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>