Re: pgsql: Fix search_path to a safe value during maintenance operations.

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: pgsql: Fix search_path to a safe value during maintenance operations.
Дата
Msg-id dba2e7d6293ee3613b0d706d79f602942022e026.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: pgsql: Fix search_path to a safe value during maintenance operations.  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
On Mon, 2023-07-31 at 13:17 -0400, Joe Conway wrote:
> But the analysis of the issue needs to go one step further. Even if
> the
> search_path does not change from the originally intended one, a newly
> created function can shadow the intended one based on argument
> coercion
> rules.

There are quite a few issues going down this path:

* The set of objects in each schema can change. Argument coercion is a
particularly subtle one, but there are other ways that it could find
the wrong object. The temp namespace also has some subtle issues.

* Schema USAGE privileges may vary over time or from caller to caller,
affecting which items in the search path are searched at all. The same
goes if theres an object access hook in place.

* $user should be resolved to a specific schema (or perhaps not in some
cases?)

* There are other GUCs and environment that can affect function
behavior. Is it worth trying to lock those down?

I agree that each of these is some potential problem, but these are
much smaller problems than allowing the caller to have complete control
over the search_path.

Regards,
    Jeff Davis




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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pltcl tests fail with FreeBSD 13.2