Re: pgsql: Fix search_path to a safe value during maintenance operations.
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <jdavis@postgresql.org>, pgsql-committers@lists.postgresql.org
Date: 2023-06-13T00:39:40Z
Lists: pgsql-hackers
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 don't think a full revert of the MAINTAIN privilege is the right thing -- the predefined role is very valuable and many other predefined roles are much more dangerous than pg_maintain is. Regards, Jeff Davis
Commits
-
Fix search_path to a safe value during maintenance operations.
- 2af07e2f749a 17.0 landed
- 05e173735171 16.0 cited
-
Revert MAINTAIN privilege and pg_maintain predefined role.
- 957445996fda 16.0 landed
- 151c22deee66 17.0 landed
-
Add grantable MAINTAIN privilege and pg_maintain role.
- 60684dd834a2 16.0 cited
-
Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.
- b073c3ccd06e 15.0 cited