On Mon, Oct 18, 2010 at 5:02 AM, KaiGai Kohei <kai...@ak.jp.nec.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
