Re: Fixing insecure security definer functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing insecure security definer functions
Date
Msg-id 1169.1171414863@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing insecure security definer functions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Fixing insecure security definer functions  (Jeff Davis <pgsql@j-davis.com>)
Re: Fixing insecure security definer functions  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Peter Eisentraut (peter_e@gmx.net) wrote:
>> Regarding the advisory on possibly insecure security definer functions
>> that I just sent out (by overriding the search path you can make the
>> function do whatever you want with the privileges of the function
>> owner), the favored solution after some initial discussion in the core
>> team was to save the search path at creation time with each function. 

> Would this be done only on security-definer functions?

I would like to see it done for all functions, security-definer or not.
There are efficiency reasons: if you keep the search path from thrashing
then you can cache plans more effectively.  (Currently, plpgsql's plan
caching doesn't pay any attention to whether the search path has
changed, but it's impossible to argue that that's not broken.)

I would suggest that the search path be added as an explicit parameter
to CREATE FUNCTION, with a default of the current setting.  The main
reason for this is that it's going to be a real PITA for pg_dump if we
don't allow an explicit specification.

It might also be worth allowing "PATH NULL" or some such locution to
specify the current behavior, for those who really want it.  (In
particular, most C functions would want this to avoid useless overhead
for calls to things that aren't affected by search path.)

Bottom line here is that this feature is really orthogonal to SECURITY
DEFINER ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] array_accum aggregate
Next
From: Tom Lane
Date:
Subject: Re: Writing triggers in C++