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
|
Список | 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 по дате отправления: