From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "Marko Tiikkaja" <marko(at)joh(dot)to>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: security_definer_search_path GUC |
Date: | 2021-06-01 06:59:23 |
Message-ID: | e9f6035e-cb1f-4c49-9286-a44ebd973d4b@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2021-06-01 07:32:33 | Re: locking [user] catalog tables vs 2pc vs logical rep |
Previous Message | tanghy.fnst@fujitsu.com | 2021-06-01 06:59:00 | RE: [BUG]Update Toast data failure in logical replication |