It affects my desktop system, but not my notebooks. Still looking into the possible difference. gdm coredumps on every boot after pam-1.6.1-1.fc40: see attachment Reproducible: Always Steps to Reproduce: 1.Update Silverblue 40 to deployment 40.20240514.0 or newer (including pam-1.6.1-1.fc40) 2.Reboot
Created attachment 2033622 [details] journalctl -b-1 -p4.log
I can't reproduce it in my environment. Can you share the coredump? I'd like to get additional information.
Created attachment 2033653 [details] core.gdm-session-wor.0.d656a95a49fe4092a70101009721298d.1372.1715895517000000.zst coredump attached
- booting with target level 3 reaches login, but login crashes. in this case /usr/bin/login coredumps. coredump of /usr/bin/login attached below any idea which files could influence this?
Created attachment 2034829 [details] core.login.0.43462dd94de54755ba15fa65fe71fac4.1448.1716488294000000.zst
found the culprit as it was always segfaulting when trying to unescape env vars from /etc/environment to reproduce: 1) set an env var of /etc/environment to a (null) value example: /etc/environment XMODIFIERS= 2) reboot 3) pam-1.6.1-1.fc40.x86_64 will segfault when trying to process /etc/environment removing the line fixes the issue on next boot
Thanks for pointing me in the right direction. If I provide a test build that fixes this issue, would you be willing to test it?
Thank you Iker. > would you be willing to test it? Absolutely!
COPR build for testing purposes: https://copr.fedorainfracloud.org/coprs/ipedrosa/pam_env_fix/
Can confirm the test build fixes the issue. Though /etc/environment XMODIFIERS= behaves different to before. While before it could be used to unset an env var via /etc/environment the line is ignored and has no effect on the logged in environment when using the test build. Is this expected behaviour?
I'm not completely sure because the documentation doesn't state anything in this regards. Can you try setting an empty string ""?
Just noticed during my testing: The issue is quite critical as it not only breaks login but also sudo. To reproduce on pam-1.6.1-1.fc40: sudo vi /etc/environment add XMODIFIERS= :wq sudo vi /etc/environment [1] 3554 segmentation fault (core dumped) sudo vi /etc/environment Process 3514 (sudo) of user 1000 dumped core. Module pam_succeed_if.so from rpm pam-1.6.1-1.fc40.x86_64 Module libpam_misc.so.0 from rpm pam-1.6.1-1.fc40.x86_64 Module pam_systemd.so from rpm systemd-255.6-1.fc40.x86_64 Module pam_limits.so from rpm pam-1.6.1-1.fc40.x86_64 Module pam_keyinit.so from rpm pam-1.6.1-1.fc40.x86_64 Without recovery actions the system is stranded after that as /etc/environment becomes un-editable.
> Can you try setting an empty string ""? (null) and empty string ("") do no longer have an effect on pam-1.6.1-2test.fc40.x86_64: $ cat /etc/environment XMODIFIERS="" $ env | grep -i XMOD XMODIFIERS=@im=ibus
FEDORA-2024-ec05ababc7 (pam-1.6.1-3.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ec05ababc7
I've built and pushed the changes that fix the problem that make the system no longer usable. Regarding the NULL assignment, this isn't clear for me so I've opened an upstream issue to check whether this is the correct behaviour or a regression: https://github.com/linux-pam/linux-pam/issues/802
*** Bug 2283058 has been marked as a duplicate of this bug. ***
FEDORA-2024-ec05ababc7 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-ec05ababc7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ec05ababc7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-ec05ababc7 (pam-1.6.1-3.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.