Re: security label support, part.2

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

Thanks,

Stephen