Re: Possible regression setting GUCs on \connect

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Steele <david(at)pgmasters(dot)net>, Alexander Korotkov <akorotkov(at)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible regression setting GUCs on \connect
Date: 2023-04-27 22:14:43
Message-ID: 20230427221443.GA1987000@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
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:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-04-27 22:18:28 Re: issue with meson builds on msys2
Previous Message Melanie Plageman 2023-04-27 21:30:40 Re: pg_stat_io for the startup process