Thread: Today's Postgres Releases break login roles
Hello,
Today, when upgrading from Postgres 15.8 to 15.9, we realized that the login role set for a user (with ALTER USER my_user SET ROLE my_role) was not automatically set upon login any more.This is particularly problematic for users of HashiCorp Vault's dynamic users (like us), who often rely on ALTER ROLE xxx SET ROLE yyy to make sure that dynamic & short-lived users created by vault create postgres resources as a long-lived role, and not as themselves.
We suspect this commit to be the one that introduced this behavioral change.
I made a little testbench with docker compose so that the problem can be reproduced easily and quickly (with comprehensive reproduction steps in the README): https://github.com/elafarge/pg_role_bug_reproduction_testbench (feel free to change the
I'm at your disposal if you have any questions.
Kind Regards,
-Étienne
Etienne LAFARGE <etienne.lafarge@gmail.com> writes:
> Today, when upgrading from Postgres 15.8 to 15.9, we realized that the
> login role set for a user (with ALTER USER my_user SET ROLE my_role) was
> not automatically set upon login any more.
Right, that was not intended. We'll fix it next week.
regards, tom lane
On Fri, Nov 15, 2024 at 06:54:00PM -0500, Tom Lane wrote: > Etienne LAFARGE <etienne.lafarge@gmail.com> writes: > > Today, when upgrading from Postgres 15.8 to 15.9, we realized that the > > login role set for a user (with ALTER USER my_user SET ROLE my_role) was > > not automatically set upon login any more. > > Right, that was not intended. We'll fix it next week. Per https://www.postgresql.org/about/news/out-of-cycle-release-scheduled-for-november-21-2024-2958/ we're issuing releases next Thursday to fix this and fix a separate ABI break. I've pushed postgr.es/c/7b88529 for $SUBJECT. To maximize time-in-buildfarm, I've pushed it without a public comment period. I welcome post-commit review, and I'm happy to amend the change if anyone finds something that would have been cause for change during a standard opportunity for pre-commit review. That said, given our wrap schedule, feedback after Saturday is less likely to change next week's releases. Such feedback could still affect the 2025-02 releases, of course. I overlooked this consequence of the 2024-11-14 change. I apologize.
Etienne LAFARGE <etienne.lafarge@gmail.com> writes: > Today, when upgrading from Postgres 15.8 to 15.9, we realized that the > login role set for a user (with ALTER USER my_user SET ROLE my_role) was > not automatically set upon login any more. I noticed one other change with the 14.14 point release, which I think is likely to be related. Previously a command like this would work to select a role immediately after login: psql "options='-crole=foo'" With 14.14 as far as I can tell it has no effect. -M-
Matthew Woodcraft <matthew@woodcraft.me.uk> writes:
> I noticed one other change with the 14.14 point release, which I think
> is likely to be related.
> Previously a command like this would work to select a role immediately after
> login:
> psql "options='-crole=foo'"
> With 14.14 as far as I can tell it has no effect.
Yeah, same issue.
regards, tom lane
Noah Misch <noah@leadboat.com> writes:
> Agreed. I cut some corners by not directly testing that or ALTER DATABASE, so
> here are some more tests. The output is the same on master @ now, on master @
> 2024-11-10 (before the regression), and on v12. It reproduces the trouble on
> master @ 2024-11-12. That's sufficient confirmation for the moment, so I'll
> hold this until the releases wrap and make it master-only.
If you only intend to apply it to master, there's no need to wait.
regards, tom lane
Thank you so much for acknowledging & fixing this so promptly Noah & Tom !!!
Have a great week both.
Best regards,
-Étienne
On Sat, Nov 16, 2024 at 9:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Noah Misch <noah@leadboat.com> writes:
> Agreed. I cut some corners by not directly testing that or ALTER DATABASE, so
> here are some more tests. The output is the same on master @ now, on master @
> 2024-11-10 (before the regression), and on v12. It reproduces the trouble on
> master @ 2024-11-12. That's sufficient confirmation for the moment, so I'll
> hold this until the releases wrap and make it master-only.
If you only intend to apply it to master, there's no need to wait.
regards, tom lane
On Sat, Nov 16, 2024 at 03:11:11PM -0500, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > Agreed. I cut some corners by not directly testing that or ALTER DATABASE, so > > here are some more tests. The output is the same on master @ now, on master @ > > 2024-11-10 (before the regression), and on v12. It reproduces the trouble on > > master @ 2024-11-12. That's sufficient confirmation for the moment, so I'll > > hold this until the releases wrap and make it master-only. > > If you only intend to apply it to master, there's no need to wait. True, the delay wasn't obligatory. I pushed it today, for whatever reason.