Re: Fix search_path for all maintenance commands - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Fix search_path for all maintenance commands
Date
Msg-id 20230609045556.GA53384@nathanxps13
Whole thread Raw
In response to Re: Fix search_path for all maintenance commands  (Greg Stark <stark@mit.edu>)
Responses Re: Fix search_path for all maintenance commands
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Next
From: Masahiko Sawada
Date:
Subject: Skip collecting decoded changes of already-aborted transactions