Re: security_definer_search_path GUC

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: security_definer_search_path GUC
Дата
Msg-id 501677FA-DD44-4724-885C-E49E03CAAA4F@enterprisedb.com
обсуждение исходный текст
Ответ на Re: security_definer_search_path GUC  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: security_definer_search_path GUC  (Isaac Morland <isaac.morland@gmail.com>)
Re: security_definer_search_path GUC  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers

> On Jun 3, 2021, at 9:38 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> This design looks good for extensions, but I am not sure if it is good for users. Some declarative way without
necessityto programming or install some extension can be nice. 

I agree, though "some declarative way" is a bit vague.  I've had ideas that perhaps superusers should be able to
furtherrestrict the [min,max] fields of int and real GUCs.  Since -1 is sometimes used to mean "disabled", syntax to
allowspecifying a set might be necessary, something like [-1, 60..600].  For text and enum GUCs, perhaps a set of
regexpswould work, some being required to match and others being required not to match, such as: 

    search_path !~ '\mcustomerx\M'
    search_path ~ '^pg_catalog,'

If we did something like this, we'd need it to play nicely with other filters provided by extensions, because I'm
reasonablysure not all filters could be done merely using set notation and regular expression syntax.  In fact, I find
ithard to convince myself that set notation and regular expression syntax would even be useful in a large enough number
ofcases to be worth implementing.  What are your thought on that? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SSL SNI
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments