Horton

Re: Fix search_path for all maintenance commands

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Noah Misch <noah@leadboat.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2023-10-27T23:04:26Z
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 →

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

  2. Make relation-enumerating operations be security-restricted operations.

On Fri, 2023-07-21 at 15:32 -0700, Jeff Davis wrote:
> Attached is a new version.

Do we still want to do this?

Right now, the MAINTAIN privilege is blocking on some way to prevent
malicious users from abusing the MAINTAIN privilege and search_path to
acquire the table owner's privileges.

The approach of locking down search_path during maintenance commands
would solve the problem, but it means that we are enforcing search_path
in some contexts and not others. That's not great, but it's similar to
what we are doing when we ignore SECURITY INVOKER and run the function
as the table owner during a maintenance command, or (by default) for
subscriptions.

My attempts to more generally try to lock down search_path for
functions attached to tables didn't seem to get much consensus, so if
we do make an exception to lock down search_path for maintenance
commands only, it would stay an exception for the foreseeable future.

Thoughts?

Regards,
	Jeff Davis