Bug 2280896

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.