Re: some namespace.c refactoring - Mailing list pgsql-hackers

From Noah Misch
Subject Re: some namespace.c refactoring
Date
Msg-id 20230216043616.GB2385625@rfd.leadboat.com
Whole thread Raw
In response to some namespace.c refactoring  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Tue, Feb 14, 2023 at 02:32:04PM +0100, Peter Eisentraut wrote:
> Notes on 0001-Refactor-is-visible-functions.patch:
> 
> Among the functions that are being unified, some check temp schemas and some
> skip them.  I suppose that this is because some (most) object types cannot
> normally be in temp schemas, but this isn't made explicit in the code.  I
> added a code comment about this, the way I understand it.
> 
> That said, you can create objects explicitly in temp schemas, so I'm not
> sure the existing code is completely correct.

> +            /*
> +             * Do not look in temp namespace for object types that don't
> +             * support temporary objects
> +             */
> +            if (!(classid == RelationRelationId || classid == TypeRelationId) &&
> +                namespaceId == myTempNamespace)
> +                continue;

I think the reason for the class-specific *IsVisible behavior is alignment
with the lookup rules that CVE-2007-2138 introduced (commit aa27977).  "CREATE
FUNCTION pg_temp.f(...)" works, but calling the resulting function requires a
schema-qualified name regardless of search_path.  Since *IsVisible functions
determine whether you can reach the object without schema qualification, their
outcomes shall reflect those CVE-2007-2138 rules.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Nikolay Samokhvalov
Date:
Subject: Re: [PATCH] Add pretty-printed XML output option