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