Re: leaky views, yet again

On Wed, Oct 13, 2010 at 12:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>
> 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.
>
> 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.  There are cases where this
> technique isn't applied at the moment but probably should be, which is
> why I characterize the leak-prevention idea as creating future security
> issues: doing that is a constraint that will have to be accounted for in
> every future planner change, and we are certain to miss the implications
> sometimes.

My concern here is that I think row-level security is important to the
future of PostgreSQL. Much of the mind-share that we have comes from
being feature-rich, and there seems to be no shortage of people who
are looking for row-level security. Only some of those are
specifically interested in SE-Linux integration; only some of those
are interested in using views as an RLS mechanism; but from a high
level RLS seems to be one of those things that just keeps bubbling
back up, and I think we need to find a way to have it. Unfortunately,
I get the impression that you think that there's a problem not only
with the approach but with any approach whatsoever to that underlying
problem. I actually can't think of a mechanism for attacking RLS that
doesn't involve some kind of planner hackery along the lines discussed
here, but if you have a better idea (other than giving up) I'm all
ears.

With respect to selectivity estimation, do we have a live bug there
now? I'm not exactly sure in what case we do this, but I observe that
I can do EXPLAIN on a query containing a function that I don't
actually have permission to call. So if the planner might go off and
call that function on some data (even data that I *am* allowed to
see), that seems bad. After all the function might be
initiate_self_destruct_sequence().

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