Re: leaky views, yet again

On Mon, Oct 18, 2010 at 5:02 AM, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> 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.

You need to go back and reread Tom's email until you understand what
he's complaining about, because it's a very serious problem. I hope
that there is a way around it, because we're not going to be able to
implement any form of row-level security - EVER - unless we figure out
how to address it. I've been mulling it over a bit and so far I'm
stumped (which is why I haven't replied). Unfortunately, I don't have
any more time to devote to this right now, so I haven't studied the
code in detail, but at the moment I'd say we're dead in the water.

I am going to mark this patch Returned with Feedback. Even were the
issue raised by Tom not a problem, it's pretty clear that this patch
as written is still going to allow an unacceptable amount of
information leakage, and wouldn't be committable anyway. But the
problem Tom raises is so severe that there's no point in writing any
more code unless and until we have a good idea what we're going to do
about it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company