Re: Fix search_path for all maintenance commands

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: Nathan Bossart <nathandbossart@gmail.com>, Greg Stark <stark@mit.edu>

Cc: pgsql-hackers@postgresql.org

Date: 2023-06-09T21:00:31Z

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, 2023-06-08 at 21:55 -0700, Nathan Bossart wrote:
> 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?

Many cases will be picked up, for instance CREATE INDEX will error if
the safe search path is not good enough.

> I'm inclined to agree that this is reasonable to desupport.

Committed.

> 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.

Agreed.

Regards,
	Jeff Davis