Date: Tue, 31 Oct 2023 11:58:02 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Noah Misch <noah@leadboat.com>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org,
	Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Fix search_path for all maintenance commands
Message-ID: <20231031165802.GB72255@nathanxps13>
References: <2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com>
 <CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ@mail.gmail.com>
 <CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com>
 <CABwTF4W5mZ+5fJEEh2vp7trGzwn-gnG6o13hAALmLjHdpeUn2g@mail.gmail.com>
 <CAKFQuwZmswfTKtx6oUY0N7UB62cO_nABMgQgdcvrD8r4qjvUJg@mail.gmail.com>
 <20230715211333.GB3675150@rfd.leadboat.com>
 <20230717175813.GA717781@nathanxps13>
 <2ad1dd4e5be5567c0d75676b348eab33b529e974.camel@j-davis.com>
 <a5960b98b7d8b655f46b4b69387f1290f5848ad4.camel@j-davis.com>
 <dfdd53fcf4be43777c81bf66ef725e28b3169ce1.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dfdd53fcf4be43777c81bf66ef725e28b3169ce1.camel@j-davis.com>
Archived-At: <https://www.postgresql.org/message-id/20231031165802.GB72255%40nathanxps13>
Precedence: bulk

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