Re: leaky views, yet again

(2010/10/14 1:52), Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> That's all true, but you have to consider how much the obstacle actually
>>> gets in their way versus how painful it is on your end to create and
>>> maintain the obstacle. �I don't think this proposed patch measures up
>>> very well on either end of that tradeoff.
>
>> I think it would behoove us to try to separate concerns about this
>> particular patch from concerns about the viability of the whole
>> approach. Whether or not it's useful to do X is a different question
>> than whether it can be done with few enough lines of code and/or
>> whether this patch actually does it well.

+1.
If the patch I proposed is not enough elegant to commit immediately,
we can discuss how we can get the patch fixing the problem commitable.

> I think I left the wrong impression: I'm concerned about the whole
> approach. I haven't even read this particular patch lately. I think
> that trying to guarantee that the planner applies independent
> constraints in a particular order will be expensive, fragile, and prone
> to recurring security bugs no matter how it's implemented --- unless you
> do it by lobotomizing query pullup/pushdown, which seems unacceptable
> from a performance standpoint.
>
It can be controllable by users. Unless specifying "SECURITY VIEW"
flag, it does not restrain a part of optimizations that allows to
execute functions which may leak the supplied arguments unexpectedly
earlier than the functions in deeper level.

Also, it does not ignore performance point of view. Even if we apply
this patch, a part of functions that we believe they don't leak any
supplied arguments can be pushed down inside of the join-loop.
Eventually, these invocations shall be utilized for index-scanning.
The reason why I, Robert and Heikki had a discussion what type of
functions should be allowed to push down is to decide a principle
to bypass this security barrier.

> Just to give one example of what this patch misses (probably; as I said
> I haven't read it lately), what about selectivity estimation? One of
> the things we like to do when we have an otherwise-unknown function is
> to try it on all the histogram members and see what percentage yield
> true. That might already represent enough of an information leak to be
> objectionable ... and yet, if we don't do it, the consequences for
> performance could be pretty horrid because we'll have to work without
> any reasonable selectivity estimate at all.

It is a bit unclear for me where is the point of your concerns.
If user wants to generate a histogram from result set of a view that
filters tuples to be invisible, it should just generate the histogram
from the filtered data set.
Even if possible malicious functions are appended to WHERE clause,
the optimizer does not execute them prior to deeper level functions,
as long as is has "SECURITY VIEW" flag.
Of course, here is a performance trade-off, as earlier researcher
pointed out, but user can inform on which does he give higher priority.

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