2010/8/14 KaiGai Kohei <kai...@kaigai.gr.jp>: > (2010/08/15 9:16), Stephen Frost wrote: >> * KaiGai Kohei (kai...@kaigai.gr.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers