Function search_path

Поиск
Список
Период
Сортировка
От Heinemann, Manfred (IMS)
Тема Function search_path
Дата
Msg-id db194d98f61d4aa398c1399a24326e7c@THALASSA.omni.imsweb.com
обсуждение исходный текст
Ответы Re: Function search_path  (Fabio Pardi <f.pardi@portavita.eu>)
Список pgsql-admin

We recently started upgrading to Postgres 10.3 and have run into trouble with the security change to search_path.

 

The release notes say:

In cases where user-provided functions are indirectly executed by these programs — for example, user-provided functions in index expressions — the tighter search_path may result in errors, which will need to be corrected by adjusting those user-provided functions to not assume anything about what search path they are invoked under. That has always been good practice, but now it will be necessary for correct behavior. (CVE-2018-1058)

 

We have this issue with a custom function that calls other custom functions and that function is used in a functional index. Now autoanalyze and autovacuum fail on tables with those indices.

 

The simplest fix seemed to be to set the functions search_path to ‘$user’ but that has caused large updates to the indexed table to run out of memory.

 

Hardcoding the schema in the function would mean having to have separate functions for each schema affected. It also seems to make the function less memory efficient.

 

Are there other options?

 

Thanks,

Manfred




Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.

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

Предыдущее
От: Ricardo Martin Gomez
Дата:
Сообщение: RE: Permission issues. Please help
Следующее
От: Fabio Pardi
Дата:
Сообщение: Re: Function search_path