KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.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. Thanks, Stephen
signature.asc
Description: Digital signature