Re: security label support, part.2

2010/8/14 KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>:
> (2010/08/15 9:16), Stephen Frost wrote:
>> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
>>> Yep, rte->requiredPerms of inherited relations are cleared on the
>>> expand_inherited_rtentry() since the v9.0, so we cannot know what
>>> kind of accesses are required on the individual child relations.
>>
>> This is really a PG issue and decision, in my view.  We're moving more
>> and more towards a decision that inherited relations are really just the
>> same relation but broken up per tables (ala "true" partitioning).  As
>> such, PG has chosen to view them as the same wrt permissions checking.
>> I don't think we should make a different decision for security labels.
>> If you don't want people who have access to the parent to have access to
>> the children, then you shouldn't be making them children.
>>
> No, what I want to do is people have identical access rights on both of
> the parent and children. If they have always same label, SE-PgSQL always
> makes same access control decision. This behavior is suitable to the
> standpoint that inherited relations are really just the same relation
> of the parent. For this purpose, I want to enforce a unique label on
> a certain inheritance tree.

This seems like a bad idea to me, too. I think it's arguable whether
access to the children should be controlled by the parent's label or
the child's label, but enforcing that the entire inheritance hierarchy
is identically labeled seems like a pointless restriction. As Stephen
points out, it's also wildly inconsistent with the way we currently
handle it.

There's also the problem that the hooks we're talking about here are
inadequate to support such a restriction anyway. You'd need some kind
of a hook in ALTER TABLE ... [NO] INHERIT, at a minimum. As has been
mentioned many times before in reviewing many generations of
SE-PostgreSQL patches, we're not going to get into the business of
re-engineering our security architecture just because you would have
designed it differently. Inventing something that's randomly
different will not only make the code ugly and hard to maintain; it
will also be confusing and difficult to manage for end-users.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company