| From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
|---|---|
| To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [v9.2] Fix leaky-view problem, part 2 |
| Date: | 2011-07-20 07:02:59 |
| Message-ID: | 4E267DA3.4030605@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kohei KaiGai | 2011-07-20 08:34:30 | Re: [v9.1] sepgsql - userspace access vector cache |
| Previous Message | Joey Adams | 2011-07-20 04:40:29 | Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON |