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

(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(at)ak(dot)jp(dot)nec(dot)com>