Re: Fix search_path for all maintenance commands

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: Greg Stark <stark@mit.edu>

Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org

Date: 2023-06-09T04:55:56Z

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 →

Fix search_path to a safe value during maintenance operations.
- 2af07e2f749a 17.0 landed
- 05e173735171 16.0 landed
Make relation-enumerating operations be security-restricted operations.
- a117cebd638d 15.0 cited

On Thu, Jun 08, 2023 at 06:08:08PM -0400, Greg Stark wrote:
> I guess that's pretty narrow and a reasonable thing to desupport.
> Users could just mark those functions with search_path or schema
> qualify the object references in them. Perhaps we should also be
> picking up cases like that sooner so users realize they've created a
> footgun for themselves?

I'm inclined to agree that this is reasonable to desupport.  Relying on the
search_path for the cases Greg describes already seems rather fragile, so
I'm skeptical that forcing a safe one for maintenance commands would make
things significantly worse.  At least, it sounds like the right trade-off
based on Jeff's note about privilege escalation risks.

I bet we could skip forcing the search_path for maintenance commands run as
the table owner, but such a discrepancy seems likely to cause far more
confusion than anything else.

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