Re: pgsql: Fix search_path to a safe value during maintenance operations.

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <jdavis@postgresql.org>, pgsql-committers@lists.postgresql.org
Date: 2023-06-13T00:20:47Z
Lists: pgsql-hackers
On Mon, 2023-06-12 at 13:33 -0400, Robert Haas wrote:
> I wonder why this commit used pg_catalog, pg_temp rather than just
> the
> empty string, as AutoVacWorkerMain does.

I followed the rules here for "Writing SECURITY DEFINER Functions
Safely":

https://www.postgresql.org/docs/16/sql-createfunction.html

which suggests adding pg_temp at the end (otherwise it is searched
first by default).

It's not exactly like a SECURITY DEFINER function, but running a
maintenance command does switch to the table owner, so the risks are
similar.

I don't see a problem with the pg_temp schema in non-interactive
processes, because we trust the non-interactive processes.

Regards,
	Jeff Davis




Commits

  1. Fix search_path to a safe value during maintenance operations.

  2. Revert MAINTAIN privilege and pg_maintain predefined role.

  3. Add grantable MAINTAIN privilege and pg_maintain role.

  4. Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.