On Sat, Nov 6, 2010 at 1:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Nov 6, 2010 at 11:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yeah, we changed that behavior as part of the fix for CVE-2007-2138.
>>> You'd need either SECURITY DEFINER functions or very careless use of
>>> SET ROLE/SET SESSION AUTHORIZATION for the issue to be exploitable.
>
>> Would it be practical to let foo() potentially mean pg_temp.foo()
>> outside of any SECURITY DEFINER context?
>
> Doesn't seem like a particularly good idea for the search semantics
> to be randomly different inside a SECURITY DEFINER function. In fact,
> I'll bet you could construct an attack in the reverse direction:
> S.D. function thinks it is calling a temp function (using syntax that
> works fine when not S.D.), but control gets sent to a non-temp function
> belonging to $badguy instead.
I guess. If you search pg_temp always then it's pretty much
impossible to avoid having a security hole, if you use any non-trivial
SQL. But if you search pg_temp for non-SD only then you'll only have
a security hole if you assume (presumably without testing) that the
behavior is the same in that case. If an SD function is calling
temporary functions they'd best be ones it created, otherwise your
security is pretty much nonexistent anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
