KaiGai,
* KaiGai Kohei (kaigai@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