On Wed, Oct 13, 2010 at 12:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
