On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > My first impression remind me an idea that I proposed before, even > though it got negative response due to user visible changes. > It requires superuser privilege to create new operators, since we > assume superuser does not set up harmful configuration.
I don't think that's acceptable from a usability point of view; this feature is important, but not important enough to go start ripping out other features that people are already using, like non-superuser operators. I'm also pretty skeptical that it would fix the problem, because the superuser might fail to realize that creating an operator was going to create this type of security exposure. After all, you and I also failed to realize that, so it's obviously a fairly subtle problem. I feel like there must be some logic in the planner somewhere that is "looking through" the subquery RTE and figuring out that safe_foo.a is really the same variable as foo.a, and which therefore feels entitled to apply !!'s selectivity estimator to foo.a's statistics. If that's the case, it might be possible to handicap that logic so that when the security_barrier flag is set, it doesn't do that, and instead treats safe_foo.a as a black box. That would, obviously, degrade the quality of complex plans involving security views, but I think we should focus on getting something that meets our security goals first and then try to improve performance later. (For example, I am fairly certain that only a superuser can install a new selectivity estimator; so perhaps we could allow selectivity estimators to be signaled with the information that a security view interposes or not, and then they can make an estimator-specific decision on how to punt; but on the other hand that might be a stupid idea; so for step #1 let's just figure out how to batten down the hatches.) -- 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
