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 |
Thread: | |
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
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 |