Re: security label support, part.2

(2010/08/18 21:52), Stephen Frost wrote:
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> If rte->requiredPerms would not be cleared, the user of the hook will
>> be able to check access rights on the child tables, as they like.
>
> This would only be the case for those children which are being touched
> in the current query, which would depend on what conditionals are
> applied, what the current setting of check_constraints is, and possibly
> other factors. I do *not* like this approach.
>
Indeed, the planner might omit scan on the children which are not obviously
referenced, but I'm not certain whether its RangeTblEntry would be also
removed from the PlannedStmt->rtable, or not.

>> How about an idea to add a new flag in RangeTblEntry which shows where
>> the RangeTblEntry came from, instead of clearing requiredPerms?
>> If the flag is true, I think ExecCheckRTEPerms() can simply skip checks
>> on the child tables.
>
> How about the external module just checks if the current object being
> queried has parents, and if so, goes and checks the
> labels/permissions/etc on those children? That way the query either
> always fails or never fails for a given caller, rather than sometimes
> working and sometimes not depending on the query.
>
Hmm, this idea may be feasible. The RangeTblEntry->inh flag of the parent
will give us a hint whether we also should check labels on its children.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>