Re: security label support, part.2

(2010/08/17 9:51), Stephen Frost wrote:
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> 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.
>
> I tend to agree. Perhaps we should bring up, in an independent thread,
> the question of if that really makes sense or if we should do something
> to prevent it (or at least issue a warning when we detect it).
>
>> 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.
>
> I tend to agree- PG isn't doing this as cleanly as it should.
>
>> 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?
>
> Yes, but that's something that should be dealt with in PG and not as
> part of an external security infrastructure. For example, PG could just
> force that the same label is applied to a child table when it's made a
> child of a particular parent, perhaps with a check to the external
> security system to see if there's a problem changing whatever label is
> on the child table before it's changed to be that of the parent, but
> once it's a child of the parent (if that operation was permitted and was
> successful), it no longer has its own 'identity'.
>
> Let's not build the complication of dealing with inheiritance/child
> relations into the external security system when we're in the middle of
> trying to get rid of that distinction in core PG though.
>
I also agree the idea that PG core handles the recursion of inheritance
hierarchy and enforce same label between them. The reason why I handled
it within the module is the core does not enforce same labels.

OK, I'll rid 'expected_parents' argument from the security hook on
relabeling. Right now, it is incomplete, but should be fixed up in
the future.

In addition, I'll also post a design proposal to keep consistency of
ownership and access privileges between parent and children.
Please also wait for a while.

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