Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-committers@lists.postgresql.org
Date: 2023-06-13T20:23:24Z
Lists: pgsql-hackers 
Noah Misch <noah@leadboat.com> writes:
> 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.

What I'm concerned about is making such a fundamental semantics change
post-beta1.  It'll basically invalidate any application compatibility
testing anybody might have done against beta1.  I think this ship has
sailed as far as v16 is concerned, although we could reconsider it
in v17.

Also, I fail to see any connection to the MAINTAIN privilege: the
committed-and-reverted patch would break things whether the user
was making any use of that privilege or not.  Thus, I do not accept
the idea that we're fixing something that's new in 16.

			regards, tom lane

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.