Re: security_definer_search_path GUC

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: security_definer_search_path GUC
Дата
Msg-id CAL9smLB-w14Rwj6OukYTwi7RsEpsi8VK2v_oSv3ndj=_MtA3tQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security_definer_search_path GUC  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
On Thu, Jun 3, 2021 at 7:30 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> On Jun 3, 2021, at 9:03 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> I agree so some possibility of locking search_path or possibility to control who and when can change it can increase security. This should be a core feature. It's maybe more generic issue - same functionality can be required for work_mem setting, maybe max_paralel_workers_per_gather, and other GUC

Chapman already suggested a mechanism in [1] to allow chaining together additional validators for GUCs.

When setting search_path, the check_search_path(char **newval, void **extra, GucSource source) function is invoked.  As I understand Chapman's proposal, additional validators could be added to any GUC.  You could implement search_path restrictions by defining additional validators that enforce whatever restriction you like.

Marko, does his idea sound workable for your needs?  I understood your original proposal as only restricting the value of search_path within security definer functions.  This idea would allow you to restrict it everywhere, and not tailored to just that context.

Yeah, that would work for my use case just as well.


.m

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

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: security_definer_search_path GUC
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: security_definer_search_path GUC