Horton

Re: Possible regression setting GUCs on \connect

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Steele <david@pgmasters.net>, Alexander Korotkov <akorotkov@postgresql.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-27T22:14:43Z
Lists: pgsql-hackers 
On Thu, Apr 27, 2023 at 03:22:04PM -0400, Tom Lane wrote:
> The right way to do this was not to add some
> poorly-explained option to ALTER ROLE, but to record the role OID that
> issued the ALTER ROLE, and then to check when loading the ALTER ROLE
> setting whether that role (still) has the right to change the
> specified setting.  As implemented, this can't possibly track changes
> in GRANT/REVOKE SET privileges correctly, and I wonder if it's not
> introducing outright security holes like the one fixed by 13d838815.

I generally agree.  At least, I think it would be nice to avoid adding a
new option if possible.  It's not clear to me why we'd need to also check
privileges at login time as opposed to only checking them at ALTER ROLE SET
time.  ISTM that the former approach would introduce some interesting
problems around dropping roles or changing roles' privileges.

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

Commits

  1. Revert "Add USER SET parameter values for pg_db_role_setting"

  2. Fix wrong construct_array_builtin() call in GUCArrayDelete()

  3. In hstore_plpython, avoid crashing when return value isn't a mapping.

  4. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.