Re: security_definer_search_path GUC
Joel Jacobson <joel@compiler.org>
From: "Joel Jacobson" <joel@compiler.org>
To: "Pavel Stehule" <pavel.stehule@gmail.com>
Cc: "Marko Tiikkaja" <marko@joh.to>,
"PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-01T06:59:23Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Create a new GUC variable search_path to control the namespace search
- 838fe25a9532 7.3.1 cited
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