2011/7/20 Yeb Havinga <yebhavi...@gmail.com>: > On 2011-07-09 09:14, Kohei KaiGai wrote: >> >> OK, I'll try to modify the patch according to the flag of pg_proc design. >> As long as the default of user-defined function is off, and we provide >> built-in functions >> with appropriate configurations, it seems to me the burden of DBA is >> quite limited. > > A different solution to the leaky view problem could be to check access to a > tuple at or near the heaptuple visibility level, in addition to adding tuple > access filter conditions to the query. This would have both the possible > performance benefits of the query rewriting solution, as the everything is > filtered before further processing at the heaptuple visibility level. Fixing > leaky views is not needed because they don't exist in this case, the code is > straightforward, and there's less change of future security bugs by either > misconfiguration of leakproof functions or code that might introduce another > leak path. > I'm not fun with this approach. The harderst one to find out a solution is a way to distinguish qualifiers of security policy and others. Leaky functions looks like a harmless function, them the optimizer will distribute them onto particular scan plans. If it was executed on the visibility check of tuples, same problem will be reproduced. So, I'm still fun with a flag of pg_proc catalog and idea of security barrier.
Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
