Re: Fix search_path for all maintenance commands

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Fix search_path for all maintenance commands
Date: 2023-10-31 16:58:02
Message-ID: 20231031165802.GB72255@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 27, 2023 at 04:04:26PM -0700, Jeff Davis wrote:
> Do we still want to do this?
>
> Right now, the MAINTAIN privilege is blocking on some way to prevent
> malicious users from abusing the MAINTAIN privilege and search_path to
> acquire the table owner's privileges.

I vote +1 for proceeding with this. You've been threatening to commit this
since July, and from a quick skim, I don't sense any sustained objections.
Given one of the main objections for v16 was the timing, I would rather
commit this relatively early in the v17 cycle so we have ample time to deal
with any breakage it reveals or to further discuss any nuances.

Of course, I am a bit biased because I would love to un-revert MAINTAIN,
but I believe others would like to see that un-reverted, too.

> The approach of locking down search_path during maintenance commands
> would solve the problem, but it means that we are enforcing search_path
> in some contexts and not others. That's not great, but it's similar to
> what we are doing when we ignore SECURITY INVOKER and run the function
> as the table owner during a maintenance command, or (by default) for
> subscriptions.

Given the experience gained from the 2018 security fixes [0], I think this
is okay.

[0] https://postgr.es/m/20230715211333.GB3675150%40rfd.leadboat.com

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2023-10-31 16:58:18 Re: Question about non-blocking mode in libpq
Previous Message Euler Taveira 2023-10-31 16:55:42 Re: Allowing TRUNCATE of FK target when session_replication_role=replica