Date: Tue, 13 Jun 2023 14:29:20 -0400
From: Noah Misch <noah@leadboat.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <jdavis@postgresql.org>,
	pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix search_path to a safe value during maintenance
 operations.
Message-ID: <20230613182920.GA259321@gust.leadboat.com>
References: <E1q7j7Y-000z1H-Hr@gemulon.postgresql.org>
 <89a415b86d5421941e4281ba5bf6288934078624.camel@j-davis.com>
 <d20864b929ff769a0ebf772359719f05bb6982cd.camel@j-davis.com>
 <573014.1686375211@sss.pgh.pa.us>
 <20230612170510.GA201972@gust.leadboat.com>
 <f53df2dbe11bb42764bcdd003a54aa29c9bb6137.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f53df2dbe11bb42764bcdd003a54aa29c9bb6137.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230613182920.GA259321%40gust.leadboat.com>
Precedence: bulk

On Mon, Jun 12, 2023 at 05:39:40PM -0700, Jeff Davis wrote:
> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> > The timing was not great, but this is fixing a purported defect in an
> > older
> > v16 feature.  If the MAINTAIN privilege is actually fine, we're all
> > set for
> > v16.  If MAINTAIN does have a material problem that $SUBJECT had
> > fixed, we
> > should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem
> > a
> > different way.
> 
> Someone with the MAINTAIN privilege on a table can use search_path
> tricks against the table owner, if the code is susceptible, because
> maintenance code runs with the privileges of the table owner.
> 
> I was concerned enough to bring it up on the -security list, and then
> to -hackers followed by a commit (too late). But perhaps that was
> paranoia: the practical risk is probably quite low, because a user with
> the MAINTAIN privilege is likely to be highly trusted.
> 
> I'd like to hear from others on the topic about the relative risks of
> shipping with/without the search_path changes.

I find shipping with the search_path change ($SUBJECT) to be lower risk
overall, though both are fairly low-risk.  Expect no new errors in non-FULL
VACUUM, which doesn't run the relevant kinds of code.  Tables not ready for
the search_path change in ANALYZE already cause errors in Autovacuum ANALYZE
and have since 2018-02 (CVE-2018-1058).  Hence, $SUBJECT poses less
compatibility risk than the CVE-2018-1058 fix.

Best argument for shipping without $SUBJECT: we already have REFERENCES and
TRIGGER privilege that tend to let the grantee hijack the table owner's
account.  Adding MAINTAIN to the list, while sad, is defensible.  I still
prefer to ship with $SUBJECT, not without.