Re: [RFC] A tackle to the leaky VIEWs for RLS

I summarized the series of discussion at: http://wiki.postgresql.org/wiki/RLS#Issue:_A_leaky_VIEWs_for_RLS

Please point out, if I missed or misunderstood something.

Thanks,

(2010/06/03 11:36), KaiGai Kohei wrote:
> (2010/06/02 12:02), KaiGai Kohei wrote:
>>> Here's another thought.  If we're leaning toward explicit syntax to
>>> designate security views (and I do mean IF, since only one person has
>>> signed on to that, even if it is Tom Lane!), then maybe we should
>>> think about ripping out the logic that causes regular views to be
>>> evaluated using the credentials of the view owner rather than the
>>> person selecting from it.  A security view would still use that logic,
>>> plus whatever additional stuff we come up with to prevent leakage.
>>> Perhaps this would be viewed as a nasty backward compatibility break,
>>> but the upside is that we'd then be being absolutely clear that a
>>> non-security view isn't and can never be trusted to be a security
>>> barrier.  Right now we're shipping something that purports to act as a
>>> barrier but really doesn't.
>>>
>>
>> Sorry, should we make clear the purpose of explicit syntax for security
>> views being issued now?
>> In my understanding, if security views, the planner tries to checks
>> privileges of the person selecting it to reference underlaying tables
>> without any ereport. If violated, the planner prevents user given
>> quals (perhaps FuncExpr only?) to come into inside of the join scan.
>> Otherwise, if regular views, the planner works as is. Right?
>>
> 
> I'd like to check up the problem in details.
> 
> We can sort out a view into three types, as follows:
> (1) A view which cannot be pulled up
> (2) A view which can be pulled up, but does not contain any joins
> (3) A view which can be pulled up, and contains joins.
> 
> For the type (1), we don't need to handle anything special, because
> no external quals are unavailable to come into.
> 
> For the type (2), we also don't need to handle anything special
> except for the evaluation order matter in ExecQual(), because it is
> impossible to distribute external quals into a part of relations.
> 
> So, the type (3) is all we have to consider here. Right?
> 
> 
> Then, where should we distinguish a security view and others?
> At least, it should be decided at pull_up_subqueries() or earlier,
> because it merges subqueries into the upper query.
> In subquery_planner(), the pull_up_subqueries() is called just after
> inline_set_returning_functions() which makes RTE_FUNCTION entry flatten
> if available. It seems to me not a strange logic to check privileges
> on underlaying relations in pull_up_subqueries(), because
> inline_set_returning_functions() also checks ACL_EXECUTE here on the
> functions to be flatten.
> 
> 
> Then, once we can identify what is a security view and not, it shall
> be marked on somewhere. Maybe, FromExpr of the pulled-up subquery?
> 
> 
> In my current idea, when a qual-node that contains FuncExpr tries to
> reference a part of relations within a security view, its referencing
> relations will be expanded to whole of the security view at
> distribute_qual_to_rels().
> Then, it will prevent a user defined function to come into inside of
> security views.
> 
> 
> At least, it seems to me reasonable to implement.
> Shall I launch to develop a proof of concept patch?
> 
> Thanks,


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>