Re: leaky views, yet again

(2010/09/02 12:38), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> (2010/09/02 11:57), Robert Haas wrote:
>>> 2010/9/1 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>> Right now, it stands on a strict assumption that considers operators
>>>> implemented with built-in functions are safe; it does not have no
>>>> possibility to leak supplied arguments anywhere.
>>>>
>>>> Please note that this patch does not case about a case when
>>>> a function inside a view and a function outside a view are
>>>> distributed into same level and the later function has lower
>>>> cost value.
>>>
>>> Without making some attempt to address these two points, I don't see
>>> the point of this patch.
>>>
>>> Also, I believe we decided previously do this deoptimization only in
>>> case the user requests it with CREATE SECURITY VIEW.
>>>
>> Perhaps, I remember the previous discussion incorrectly.
>>
>> If we have a hint about whether the supplied view is intended to security
>> purpose, or not, it seems to me it is a reliable method to prevent pulling
>> up the subqueries come from security views.
>> Is it too much deoptimization?
>
> Well, that'd prevent something like id = 3 from getting pushed down,
> which seems a bit harsh.
>
Hmm. If so, we need to remember what FromExpr was come from subqueries
of security views, and what were not. Then, we need to prevent leakable
clause will be distributed to inside of them.
In addition, we also need to care about the order of function calls in
same level, because it is not implicitly solved.

At first, let's consider top-half of the matter.

When views are expanded into subqueries in query-rewriter, Query tree
lost an information OID of the view, because RangeTblEntry does not have
OID of the relation when it is RTE_SUBQUERY. So, we need to patch here
to mark a flag whether the supplied view is security focused, or not.

Then, pull_up_simple_subquery() pulls up a supplied subquery into normal
join, if possible. In this case, FromExpr is chained into the upper level.
Of course, FromExpr does not have a flag to show its origin, so we also
need to copy the new flag in RangeTblEntry to FromExpr.

Then, when distribute_qual_to_rels() is called, the caller also provides
a Bitmapset of relation-Ids which are contained under the FromExpr with
the flag saying it came from the security views.
Even if the supplied clause references a part of the Bitmapset, we need
to prevent the clause being pushed down into the relations came from
security views, except for ones we can make sure these are safe.

Perhaps, it is not impossible....

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