Re: security_definer_search_path GUC
| От | Isaac Morland |
|---|---|
| Тема | Re: security_definer_search_path GUC |
| Дата | |
| Msg-id | CAMsGm5dLz3wRvsDj-Y1hr6uGUYUmmwaxcp-VuAZK+-5hr_dFXw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: security_definer_search_path GUC (Mark Dilger <mark.dilger@enterprisedb.com>) |
| Ответы |
Re: security_definer_search_path GUC
("Joel Jacobson" <joel@compiler.org>)
|
| Список | pgsql-hackers |
I thought everybody was already doing this, but maybe not. I put the following in all my function definitions:
SET search_path FROM CURRENT
(with the exception of a very few functions which explicitly need to use the caller's search path)
It seems to me that if this was the default (note: I'm totally ignoring backward compatibility issues for now), then most of these issues wouldn't exist. My schema creation scripts start with an appropriate search path setting and that value then gets built into every function they create.
Related question: how can function compilation work when the behaviour depends on the search path of the caller? In other words, the behaviour of the function can be totally different on each call. Are there any popular programming environments in which the behaviour of a called function depends on the caller's environment (actually yes: shell scripting, with $PATH especially; but besides that and stored procedures)?
I also want to mention that I consider any suggestion to eliminate the search_path concept as a complete non-starter. It would be no different from proposing that the next version of a programming language eliminate (or stop using) the module system. If I could make it happen easily, I would go in the other direction and allow schemas to be hierarchical (note: totally ignoring all sorts of very important choices which are more than just details about how this should work). I would like to be able to have an extension or subsystem exist in a single schema, with its objects broken up into schemas within the schema. Same reason as most languages have hierarchical module systems.
On Thu, 3 Jun 2021 at 14:25, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> 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 necessity to 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 further restrict the [min,max] fields of int and real GUCs. Since -1 is sometimes used to mean "disabled", syntax to allow specifying a set might be necessary, something like [-1, 60..600]. For text and enum GUCs, perhaps a set of regexps would 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 reasonably sure not all filters could be done merely using set notation and regular expression syntax. In fact, I find it hard to convince myself that set notation and regular expression syntax would even be useful in a large enough number of cases to be worth implementing. What are your thought on that?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: