Re: Fixing insecure security definer functions

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Fixing insecure security definer functions
Дата
Msg-id 200705291236.40534.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: Fixing insecure security definer functions  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Fixing insecure security definer functions  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Stephen, Tom,

> > Eeek.  *Which* caller's search_path?  The string you're handed
> > might've come from multiple levels up.
>
> I would say the outer-most.  If people inbetween want to mess with
> things, let them qualify it before handing it down.  Clearly, an
> already-qualified object would be left alone.

Based on further IRC, I can personally see a solution which would be 
generally useful.  Further, this solution doesn't require (or shouldn't) 
any modification of the existing function_path solution.  It just requires 
two functions, which could be developed now or later:

1) pg_get_caller_path() == returns the search_path of the calling session, 
which presumably is being stored somewhere for reversion when the final 
nested function exits.

2) pg_get_object_fullname(name, path) == returns the fully-qualified object 
name of an object based on the path supplied.

In addition to Stephen's peculiar application, I can see these functions 
being useful for a variety of applications which might mix path-set 
functions with pathless functions, or which use hundreds of schema to 
isolate user objects.

However, I don't see this as being anything which would hold up 8.3, since 
function_path doesn't break anything which was already working.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Feature freeze status report
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Create hooks to let a loadable plugin monitor (or even replace)