Re: security_definer_search_path GUC
От | Pavel Stehule |
---|---|
Тема | Re: security_definer_search_path GUC |
Дата | |
Msg-id | CAFj8pRCOQqJECXde_1Oms9jhte+tKLo_q5XY3n=xX9va7bR7BA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: security_definer_search_path GUC ("Joel Jacobson" <joel@compiler.org>) |
Ответы |
Re: security_definer_search_path GUC
|
Список | pgsql-hackers |
út 1. 6. 2021 v 8:59 odesílatel Joel Jacobson <joel@compiler.org> napsal:
On Sun, May 30, 2021, at 09:54, Pavel Stehule wrote:Maybe inverted design can work better - there can be GUC - "qualified_names_required" with a list of schemas without enabled implicit access.The one possible value can be "all".The advantage of this design can be the possibility of work on current extensions.I don't think so search_path can be disabled - but there can be checks that disallow non-qualified names.I would prefer a pre-installed search_path-extension that can be uninstalled,instead of yet another GUC, but if that's not an option, I'm happy with a GUC as well.IMO, the current search_path default behaviour is a minefield.For users like myself, who prefer a safer context-free name resolution behaviour, here is how I think it should work:* The only schemas that don't require fully-qualified schemas are 'pg_catalog' and 'public'* The $user schema feature is removed, i.e:- $user is not part of the search_path- objects are not created nor looked for in a $user schema if such a schema exists- objects are always created in 'public' if a schema is not explicitly specified* Temp objects always needs to be fully-qualified using 'pg_temp'* 'pg_catalog' and 'public' are enforced to be completely disjoint.That is, trying to create an object in 'public' that is in conflict with 'pg_catalog' would raise an error.More ideas?
Operators use schemas too. I cannot imagine any work with operators with the necessity of explicit schemas.
Regards
Pavel
/Joel
В списке pgsql-hackers по дате отправления: