Re: Fix search_path for all maintenance commands

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix search_path for all maintenance commands
Date: 2023-06-09 04:55:56
Message-ID: 20230609045556.GA53384@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-06-09 05:16:44 Skip collecting decoded changes of already-aborted transactions
Previous Message Drouvot, Bertrand 2023-06-09 04:26:07 Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN