Re: MAINTAIN privilege -- what do we need to un-revert it? - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: MAINTAIN privilege -- what do we need to un-revert it?
Date
Msg-id 20240223213055.GA1805646@nathanxps13
Whole thread Raw
In response to Re: MAINTAIN privilege -- what do we need to un-revert it?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MAINTAIN privilege -- what do we need to un-revert it?
List pgsql-hackers
(Apologies in advance for anything I'm bringing up that we've already
covered somewhere else.)

On Fri, Feb 16, 2024 at 04:03:55PM -0800, Jeff Davis wrote:
> Note the changes in amcheck. It's creating functions and calling those
> functions from the comparators, and so the comparators need to set the
> search_path. I don't think that's terribly common, but does represent a
> behavior change and could break something.

Why is this change needed?  Is the idea to make amcheck follow the same
rules as maintenance commands to encourage folks to set up index functions
correctly?  Or is amcheck similarly affected by search_path tricks?

>  void
>  InitializeSearchPath(void)
>  {
> +    /* Make the context we'll keep search path cache hashtable in */
> +    SearchPathCacheContext = AllocSetContextCreate(TopMemoryContext,
> +                                                   "search_path processing cache",
> +                                                   ALLOCSET_DEFAULT_SIZES);
> +
>      if (IsBootstrapProcessingMode())
>      {
>          /*
> @@ -4739,11 +4744,6 @@ InitializeSearchPath(void)
>      }
>      else
>      {
> -        /* Make the context we'll keep search path cache hashtable in */
> -        SearchPathCacheContext = AllocSetContextCreate(TopMemoryContext,
> -                                                       "search_path processing cache",
> -                                                       ALLOCSET_DEFAULT_SIZES);
> -

What is the purpose of this change?

> +    SetConfigOption("search_path", GUC_SAFE_SEARCH_PATH, PGC_USERSET,
> +                    PGC_S_SESSION);

I wonder if it's worth using PGC_S_INTERACTIVE or introducing a new value
for these.

> +/*
> + * Safe search path when executing code as the table owner, such as during
> + * maintenance operations.
> + */
> +#define GUC_SAFE_SEARCH_PATH "pg_catalog, pg_temp"

Is including pg_temp actually safe?  I worry that a user could use their
temporary schema to inject objects that would take the place of
non-schema-qualified stuff in functions.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is subscription/t/031_column_list.pl failing so much?
Next
From: Nathan Bossart
Date:
Subject: Re: cleanup patches for dshash