Horton

Re: pgsql: Fix search_path to a safe value during maintenance operations.

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-06-29T20:29:40Z
Lists: pgsql-hackers 
On Thu, Jun 29, 2023 at 11:19:38AM -0400, Robert Haas wrote:
> [ emerges from hibernation ]

Welcome back.

> If we're not going to fix the feature so that it doesn't break the
> security model, we should probably just revert it. I don't understand
> at all the idea of shipping something that we 100% know is broken.

Given Jeff's commit followed the precedent set by the fix for
CVE-2018-1058, I'm inclined to think he was on the right track.  Perhaps a
more targeted fix, such as only changing search_path when the command is
not run by the table owner (as suggested upthread [0]) is worth
considering.

[0] https://postgr.es/m/CAKFQuwaVJkM9u%2BqpOaom2UkPE1sz0BASF-E5amxWPxncUhm4Hw%40mail.gmail.com

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

Commits

  1. Fix search_path to a safe value during maintenance operations.

  2. Revert MAINTAIN privilege and pg_maintain predefined role.

  3. Add grantable MAINTAIN privilege and pg_maintain role.

  4. Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.