Re: security label support, part.2 - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: security label support, part.2
Date
Msg-id 4C6C7BD0.3090101@ak.jp.nec.com
Whole thread Raw
In response to Re: security label support, part.2  (Stephen Frost <sfrost@snowman.net>)
Responses Re: security label support, part.2
List pgsql-hackers
(2010/08/18 21:52), Stephen Frost wrote:
> * KaiGai Kohei (kaigai@ak.jp.nec.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@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!
Next
From: KaiGai Kohei
Date:
Subject: Re: security label support, part.2