Re: [v9.2] Fix leaky-view problem, part 2
Noah Misch <noah@2ndquadrant.com>
From: Noah Misch <noah@2ndQuadrant.com>
To: Yeb Havinga <yebhavinga@gmail.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Kohei Kaigai <Kohei.Kaigai@emea.nec.com>, Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-07-20T14:06:26Z
Lists: pgsql-hackers
On Wed, Jul 20, 2011 at 09:02:59AM +0200, Yeb Havinga wrote: > 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. The SQL-level semantics of the view define the access rules in question. How would you translate that into tests to apply at a lower level? -- Noah Misch http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services