FS#67636 - [pam] Can't login using pam 1.4 with certain .pam_environment contents

Attached to Project: Arch Linux
Opened by Bitwave (bitwave) - Wednesday, 19 August 2020, 09:53 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 14 November 2020, 11:47 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No

Details

Description:

After upgrading pam to pam-1.4.0-3 and pambase to pambase 20200721.1-2 I was unable to login.

Aug 19 10:58:27 moritz-arch systemd[1]: Starting User Manager for UID 1000...
Aug 19 10:58:27 moritz-arch dbus-daemon[455]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.ho>
Aug 19 10:58:27 moritz-arch dbus-daemon[455]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org>
Aug 19 10:58:27 moritz-arch systemd[2488]: pam_systemd_home(systemd-user:account): Failed to query user record: Unit dbus-org.freedesktop.home1.s>
Aug 19 10:58:27 moritz-arch audit[2488]: USER_ACCT pid=2488 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_u>
Aug 19 10:58:27 moritz-arch audit[2488]: CRED_ACQ pid=2488 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=? acct="moritz" exe=>
Aug 19 10:58:27 moritz-arch systemd[2488]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal>
Aug 19 10:58:27 moritz-arch systemd[2488]: pam_unix(systemd-user:session): session opened for user moritz(uid=1000) by (uid=0)
Aug 19 10:58:27 moritz-arch audit[2488]: USER_START pid=2488 uid=0 auid=1000 ses=14 msg='op=PAM:session_open grantors=? acct="moritz" exe="/usr/l>
Aug 19 10:58:27 moritz-arch systemd[2488]: PAM failed: Critical error - immediate abort
Aug 19 10:58:27 moritz-arch systemd[2488]: user@1000.service: Failed to set up PAM session: Operation not permitted
Aug 19 10:58:27 moritz-arch systemd[2488]: user@1000.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Aug 19 10:58:27 moritz-arch systemd[1]: user@1000.service: Main process exited, code=exited, status=224/PAM
Aug 19 10:58:27 moritz-arch systemd[1]: user@1000.service: Failed with result 'exit-code'.
Aug 19 10:58:27 moritz-arch systemd[1]: Failed to start User Manager for UID 1000.


Steps to reproduce:

- upgrade to earlier mentioned version via normal pacman -Syu
- expected: login after restart works
- login does not work
- after downgrading pam and pambase to previous version pam-1.3.1-2 and pambase-20190105.1-2 login works again.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 14 November 2020, 11:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  pam 1.5.0-1
Comment by loqs (loqs) - Wednesday, 19 August 2020, 10:14 GMT
Do you have any unmerged .pacnew or .pacsave files in /etc/pam.d/?

What is the contents of /etc/pam.d/systemd-user
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 11:00 GMT
-rw-r--r-- 1 root root 160 15. Jul 22:15 chage
-rw-r--r-- 1 root root 160 23. Jul 20:39 chfn
-rw-r--r-- 1 root root 103 15. Jul 22:15 chgpasswd
-rw-r--r-- 1 root root 174 15. Jul 22:15 chpasswd
-rw-r--r-- 1 root root 160 23. Jul 20:39 chsh
-rw-r--r-- 1 root root 87 16. Jul 12:43 cups
-rw-r--r-- 1 root root 160 15. Jul 22:15 groupadd
-rw-r--r-- 1 root root 160 15. Jul 22:15 groupdel
-rw-r--r-- 1 root root 103 15. Jul 22:15 groupmems
-rw-r--r-- 1 root root 160 15. Jul 22:15 groupmod
-rw-r--r-- 1 root root 171 7. Jul 20:05 i3lock
-rw-r--r-- 1 root root 220 23. Jul 20:39 login
-rw-r--r-- 1 root root 174 15. Jul 22:15 newusers
-rw-r--r-- 1 root root 274 13. Nov 2019 other
-rw-r--r-- 1 root root 198 15. Jul 22:15 passwd
-rw-r--r-- 1 root root 155 3. Aug 09:49 polkit-1
-rw-r--r-- 1 root root 87 21. Jun 12:42 postgresql
-rw-r--r-- 1 root root 500 13. Nov 2019 rlogin
-rw-r--r-- 1 root root 425 13. Nov 2019 rsh
-rw-r--r-- 1 root root 76 23. Jul 20:39 runuser
-rw-r--r-- 1 root root 76 23. Jul 20:39 runuser-l
-rw-r--r-- 1 root root 27 6. Feb 2020 screen
-rw-r--r-- 1 root root 160 15. Jul 22:15 shadow
-rw-r--r-- 1 root root 232 16. Jul 22:16 sshd
-rw-r--r-- 1 root root 366 23. Jul 20:39 su
-rw-r--r-- 1 root root 97 22. Jul 16:15 sudo
-rw-r--r-- 1 root root 366 23. Jul 20:39 su-l
-rw-r--r-- 1 root root 441 13. Nov 2019 system-auth
-rw-r--r-- 1 root root 132 19. Aug 10:05 systemd-user
-rw-r--r-- 1 root root 143 13. Nov 2019 system-local-login
-rw-r--r-- 1 root root 713 13. Nov 2019 system-login
-rw-r--r-- 1 root root 143 13. Nov 2019 system-remote-login
-rw-r--r-- 1 root root 260 13. Nov 2019 system-services
-rw-r--r-- 1 root root 160 15. Jul 22:15 useradd
-rw-r--r-- 1 root root 160 15. Jul 22:15 userdel
-rw-r--r-- 1 root root 160 15. Jul 22:15 usermod
-rw-r--r-- 1 root root 124 14. Aug 14:24 vlock

Doesn't seem so.

cat /etc/pam.d/systemd-user
# Used by systemd --user instances.

account include system-login
session required pam_loginuid.so
session include system-login


Comment by Andreas Liebig (lutey) - Wednesday, 19 August 2020, 12:47 GMT
I had the same issue.

However, in my case I noticed that system-login.pacnew was created.

Investigating the differences, it turns out that in my case
auth required pam_tally2.so
caused the issue.

Removed the module solved the login problem, without having to downgrade.

Maybe this helps
Comment by Tobias Powalowski (tpowa) - Wednesday, 19 August 2020, 14:48 GMT
grep tally2 /etc/pam.d/*
It was removed in pam 1.4.0.
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 15:06 GMT
grep tally2 /etc/pam.d/* gives exitcode 1 for me.

I have to say I use a vanilla pam configuration without any custom modifications except for ones installed by packages.
Comment by Andreas Liebig (lutey) - Wednesday, 19 August 2020, 15:11 GMT
Theoretically it could also be the pam_tally module (pam_tally.so), so:
grep tally /etc/pam.d/*
Comment by Pavel (aslpavel) - Wednesday, 19 August 2020, 15:14 GMT
I have exactly the same problem, can not login anymore. I do not have any outdated files in the pam.d directory. Errors in the logs looks very much like in the description.
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 15:18 GMT
@Andreas grep tally /etc/pam.d/* gives the same as tally2 before. No match.
Comment by JD Wang (JDWUP) - Wednesday, 19 August 2020, 15:37 GMT
It looks like pam_tally and pam_tally2 are deprecated[0].


[0]: https://github.com/linux-pam/linux-pam/commit/f49166c7d8f3ae2c9d337154f7e5dc50d41ab6bf
Comment by Maxime Durand (emixam) - Wednesday, 19 August 2020, 15:59 GMT
I had the same issue too. And I had to downgrade the package.

I had to merge `/etc/pam.d/system-login`. I tested with the version of the package, my old version or the merged version. No change between the three.

``` bash
Aug 19 16:57:35 gdm-password][1636]: pam_systemd_home(gdm-password:auth): Failed to query user record: Unit dbus-org.freedesktop.home1.service not found.
Aug 19 16:57:40 gdm-password][1640]: PAM unable to dlopen(/usr/lib/security/pam_tally2.so): /usr/lib/security/pam_tally2.so: Ne peut ouvrir le fichier d'o>
Aug 19 16:57:40 gdm-password][1640]: PAM adding faulty module: /usr/lib/security/pam_tally2.so
Aug 19 16:58:03 gdm-password][1640]: gkr-pam: unable to locate daemon control file
Aug 19 16:58:09 gdm-password][1710]: PAM unable to dlopen(/usr/lib/security/pam_tally2.so): /usr/lib/security/pam_tally2.so: Ne peut ouvrir le fichier d'o>
Aug 19 16:58:09 gdm-password][1710]: PAM adding faulty module: /usr/lib/security/pam_tally2.so
```

And indeed I didn't have libs like `pam_tally2.so` or others (whose names I don't have anymore) in `/usr/lib/security/`.
Comment by loqs (loqs) - Wednesday, 19 August 2020, 16:22 GMT
@bitwave if you modify /etc/pam.d/systemd-user to match the attached systemd-user can you still reproduce the issue?
   systemd-user (0.2 KiB)
Comment by Maxime Durand (emixam) - Wednesday, 19 August 2020, 16:24 GMT
Sorry error refresh.
Comment by Pavel (aslpavel) - Wednesday, 19 August 2020, 16:27 GMT
@loqs I'm not @bitwave, but having same problem, this change does not have any effect for me.
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 16:27 GMT
I modified it, doesn't change anything.
Comment by loqs (loqs) - Wednesday, 19 August 2020, 16:34 GMT
Aug 19 10:58:27 moritz-arch systemd[2488]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal>
Aug 19 10:58:27 moritz-arch systemd[2488]: pam_unix(systemd-user:session): session opened for user moritz(uid=1000) by (uid=0)

grep -r pam_warn.so /etc/pam.d/
/etc/pam.d/other:auth required pam_warn.so
/etc/pam.d/other:account required pam_warn.so
/etc/pam.d/other:password required pam_warn.so
/etc/pam.d/other:session required pam_warn.so

Try adding to /etc/pam.d/systemd-user
auth required pam_permit.so
password required pam_permit.so
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 16:38 GMT
Same again:

Aug 19 18:36:33 moritz-arch audit[102821]: USER_AUTH pid=102821 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock acct="moritz" exe="/usr/bin/login" hostname=moritz-arch addr=? terminal=tty3 res=success'
Aug 19 18:36:33 moritz-arch dbus-daemon[455]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.1986' (uid=0 pid=102821 comm="/bin/login -p -- ")
Aug 19 18:36:33 moritz-arch dbus-daemon[455]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Aug 19 18:36:33 moritz-arch login[102821]: pam_systemd_home(login:account): Failed to query user record: Unit dbus-org.freedesktop.home1.service not found.
Aug 19 18:36:33 moritz-arch audit[102821]: USER_ACCT pid=102821 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct="moritz" exe="/usr/bin/login" hostname=moritz-arch addr=? terminal=tty3 res=success'
Aug 19 18:36:33 moritz-arch audit[102821]: CRED_ACQ pid=102821 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock acct="moritz" exe="/usr/bin/login" hostname=moritz-arch addr=? terminal=tty3 res=success'
Aug 19 18:36:33 moritz-arch login[102821]: pam_unix(login:session): session opened for user moritz(uid=1000) by LOGIN(uid=0)
Aug 19 18:36:33 moritz-arch systemd-logind[459]: New session 43 of user moritz.
Aug 19 18:36:33 moritz-arch systemd[1]: Started Session 43 of user moritz.
Aug 19 18:36:33 moritz-arch audit[102821]: USER_START pid=102821 uid=0 auid=1000 ses=43 msg='op=PAM:session_open grantors=? acct="moritz" exe="/usr/bin/login" hostname=moritz-arch addr=? terminal=tty3 res=failed'
Aug 19 18:36:33 moritz-arch audit[102821]: CRED_DISP pid=102821 uid=0 auid=1000 ses=43 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock acct="moritz" exe="/usr/bin/login" hostname=moritz-arch addr=? terminal=tty3 res=success'
Aug 19 18:36:33 moritz-arch login[102821]: Critical error - immediate abort
Comment by loqs (loqs) - Wednesday, 19 August 2020, 16:55 GMT
The pam_warn entries were not related then. Please restore /etc/pam.d/systemd-user to its original contents.

Does pacman -Qkk detect any changed or missing files in /etc/pam.d ?
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 17:05 GMT
German locale, sry

/e/pam.d> sudo pacman -Qkk (pacman -Qo * | awk { print \$4 } | sort | uniq)
Warnung: cups: /etc/cups/classes.conf (Berechtigungen stimmen nicht überein)
Sicherungs-Datei: cups: /etc/cups/classes.conf (Zeit der Veränderung stimmt nicht überein)
Sicherungs-Datei: cups: /etc/cups/classes.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/printers.conf (Berechtigungen stimmen nicht überein)
Sicherungs-Datei: cups: /etc/cups/printers.conf (Zeit der Veränderung stimmt nicht überein)
Sicherungs-Datei: cups: /etc/cups/printers.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Berechtigungen stimmen nicht überein)
Sicherungs-Datei: cups: /etc/cups/subscriptions.conf (Zeit der Veränderung stimmt nicht überein)
Sicherungs-Datei: cups: /etc/cups/subscriptions.conf (Größen stimmen nicht überein)
cups: 874 Dateien gesamt, 3 veränderte Dateien
i3lock: 13 Dateien gesamt, 0 veränderte Dateien
inetutils: 56 Dateien gesamt, 0 veränderte Dateien
kbd: 775 Dateien gesamt, 0 veränderte Dateien
openssh: 59 Dateien gesamt, 0 veränderte Dateien
pambase: 8 Dateien gesamt, 0 veränderte Dateien
polkit: 201 Dateien gesamt, 0 veränderte Dateien
postgresql: 2807 Dateien gesamt, 0 veränderte Dateien
screen: 38 Dateien gesamt, 0 veränderte Dateien
Warnung: shadow: /usr/bin/newgidmap (Berechtigungen stimmen nicht überein)
Warnung: shadow: /usr/bin/newuidmap (Berechtigungen stimmen nicht überein)
shadow: 558 Dateien gesamt, 2 veränderte Dateien
Sicherungs-Datei: sudo: /etc/sudoers (Zeit der Veränderung stimmt nicht überein)
Sicherungs-Datei: sudo: /etc/sudoers (Größen stimmen nicht überein)
sudo: 223 Dateien gesamt, 0 veränderte Dateien
Sicherungs-Datei: systemd: /etc/pam.d/systemd-user (Zeit der Veränderung stimmt nicht überein) Change time doesnt match
Sicherungs-Datei: systemd: /etc/pam.d/systemd-user (Größen stimmen nicht überein) filesize doesnt match
Sicherungs-Datei: systemd: /etc/systemd/journald.conf (Zeit der Veränderung stimmt nicht überein)
Sicherungs-Datei: systemd: /etc/systemd/journald.conf (Größen stimmen nicht überein)
Warnung: systemd: /var/log/journal (GID stimmt nicht überein)
systemd: 1820 Dateien gesamt, 1 veränderte Datei
util-linux: 506 Dateien gesamt, 0 veränderte Dateien
Comment by loqs (loqs) - Wednesday, 19 August 2020, 17:16 GMT
@bitwave downgrade pambase leaving pam at 1.4. To make pambase-20190105.1-2 compatible with pam 1.4 comment out the pam_tally2.so entries in /etc/pam.d/system-login

If this works the issue is in the pambase changes not the pam 1.4 update.
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 17:22 GMT
@loqs this works. Therefore the pambase is the problem
Comment by loqs (loqs) - Wednesday, 19 August 2020, 17:33 GMT
Does the directory /run/faillock exist?

If it does please upgrade pambase and replace system-auth with the one attached. The attached one removes pam-systemd-homed support.
   system-auth (1.1 KiB)
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 17:37 GMT
1. yes, it exists

Aug 19 19:36:33 moritz-arch audit[121989]: USER_AUTH pid=121989 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_secu>
Aug 19 19:36:33 moritz-arch audit[121989]: USER_ACCT pid=121989 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,p>
Aug 19 19:36:33 moritz-arch audit[121989]: CRED_ACQ pid=121989 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_securetty,pa>
Aug 19 19:36:33 moritz-arch login[121989]: pam_unix(login:session): session opened for user moritz(uid=1000) by LOGIN(uid=0)
Aug 19 19:36:33 moritz-arch systemd-logind[459]: New session 48 of user moritz.
Aug 19 19:36:33 moritz-arch systemd[1]: Started Session 48 of user moritz.
Aug 19 19:36:33 moritz-arch audit[121989]: USER_START pid=121989 uid=0 auid=1000 ses=48 msg='op=PAM:session_open grantors=? acct="moritz" exe="/u>
Aug 19 19:36:33 moritz-arch audit[121989]: CRED_DISP pid=121989 uid=0 auid=1000 ses=48 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_>
Aug 19 19:36:33 moritz-arch login[121989]: Critical error - immediate abort
Comment by loqs (loqs) - Wednesday, 19 August 2020, 17:47 GMT
What if you comment out the last line of /etc/pam.d/system-login?
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 17:52 GMT
you mean: "session required pam_env.so user_readenv=1"?
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 17:52 GMT
It works!
Comment by loqs (loqs) - Wednesday, 19 August 2020, 17:58 GMT
If you uncomment the line then change user_readenv=1 to user_readenv=0 and it still works the issue is in $HOME/.pam_environment otherwise it should be in /etc/security/pam_env.conf or /etc/environment.
Comment by Bitwave (bitwave) - Wednesday, 19 August 2020, 18:01 GMT
user_readenv=0 solves it.
Comment by solsTiCe (zebul666) - Wednesday, 19 August 2020, 21:18 GMT
This is a critical bug. I was locked out of a runnning machine because my session locked out after I did the upgrade.

And I don't understand why /etc/pam.d/system-login on my laptop uses pam_tally2 while my netbook does not .I don't remember changing anything. Never mind, this is not the real problem.
Comment by loqs (loqs) - Wednesday, 19 August 2020, 22:00 GMT
@zebul666 pam_tally2 removal is covered by  FS#67641 . You also have an issue caused by pam_env.so?
Comment by G3ro (G3ro) - Wednesday, 19 August 2020, 22:21 GMT
Maybe maintainers could use older configs next time, to test this before rolling out.

Normally all errors are not a problem, because you can still login, see what the problem is and solve it.

But this time it cost me one hour to figure it all out.
Comment by loqs (loqs) - Wednesday, 19 August 2020, 22:33 GMT
@G3ro please read through [1] [2] [3]. The issue is not old configs, it is user modified configs.

[1] https://wiki.archlinux.org/index.php/System_maintenance#Deal_promptly_with_new_configuration_files
[2] https://lists.archlinux.org/pipermail/arch-general/2020-August/048061.html
[3] https://lists.archlinux.org/pipermail/arch-general/2020-August/048062.html
Comment by Cole Deck (thirstyshark) - Thursday, 20 August 2020, 00:20 GMT
I'm encountering a similar issue, after upgrade I can log in the first time (to start SDDM and get into my plasma desktop). but then after that in my session sudo will say try again, I am 100% sure my password is correct. After that I cannot login with tty, it says the account is locked and I have to wait 10 minutes. I tried a couple things to unlock it as root, including passwd -u, none of which worked. There were no .pacnew files in /etc/pam.d/, and I even removed /etc/pam.d and reinstalled all packages to be sure. I have never changed any pam files from the defaults.

Unfortunately downgrade for some reason made it worse, it didn't even let me log in as root anymore, it just said "login incorrect" for both root and my user with no 10 minute cooldown like i get on the latest version.
Comment by loqs (loqs) - Thursday, 20 August 2020, 00:35 GMT
pam_env is rejecting previously allowed $HOME/.pam_environment files [1] [2] such as

SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Possibly caused by [3]

@thirstyshark you can use faillock --user $USERNAME --reset to clear the faillock, you can also change the lockout options in /etc/security/faillock.conf

[1] https://bbs.archlinux.org/viewtopic.php?id=258324
[2] https://bbs.archlinux.org/viewtopic.php?id=258320
[3] https://github.com/linux-pam/linux-pam/commit/563d21d6dbb6d64613919ccb1cc939bae546baab

For those affected does `grep -Pa '\x00' .pam_environment` produce any output?
Comment by Bitwave (bitwave) - Thursday, 20 August 2020, 07:54 GMT
For me grep -Pa '\x00' .pam_environment does not produce any output.

contens are:

$ cat .pam_environment
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
Comment by Pavel (aslpavel) - Thursday, 20 August 2020, 08:30 GMT
`grep -Pa '\x00'` no result, but in my case it is symlink.
Comment by G3ro (G3ro) - Thursday, 20 August 2020, 12:10 GMT
@loqs

Thx for the explanation.

My problem is probably pamac: https://gitlab.manjaro.org/applications/pamac/-/issues/877

Still I would recommend to put the explanation about .pacnew somewhere where everyone surely reads it, like a page "Important Notes" or something.
Because even though I read through all these pages, I must have somehow read over this.
Comment by Morten Linderud (Foxboron) - Thursday, 20 August 2020, 12:18 GMT
It's written on the "System Maintenance" page on the wiki, which are linked from General Recommendations listed in the Installation Guide.

https://wiki.archlinux.org/index.php/System_maintenance#Deal_promptly_with_new_configuration_files

.pacnew files are also explicitly mentioned in the `pacman` man page, https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a
Comment by loqs (loqs) - Thursday, 20 August 2020, 13:15 GMT
If you change the pam_env line to

session required pam_env.so debug user_readenv=1

There should be more output in the journal.

@bitwave what if you change the XMODIFIERS entry to:

XMODIFIERS=\@im=fcitx
Comment by Ilia Baryshnikov (qwemaze) - Thursday, 20 August 2020, 14:20 GMT
Had same issue, it looks like I got it fixed by adding trailing newline to $HOME/.pam_environment
Comment by Antoine Viallon (aviallon) - Thursday, 20 August 2020, 14:40 GMT
It seems I got exactly the same issue...
And since this bug completely locks someone out of its computer (requiring a LiveUSB or another computer if you don't have one ready), it really shouldn't be a "Low" severity bug.
Since it seems to only affect modified config (which I can verify), it may not be very high priority...
But please. This is not "Low" severity.
Comment by Maxime Durand (emixam) - Thursday, 20 August 2020, 15:12 GMT
I couldn't agree with you more.

I am aware of .pacnew and I make the necessary changes systematically. But this is clearly not enough. Having to downgrade the package from a LiveUSB shouldn't be a low severity!

By the way, for people who have followed the recommendations on this page: https://wiki.archlinux.org/index.php/Security, have necessarily these files (system-login passwd) or modified. So it must (or will) happen to many people who keep their Arch Linux up to date.
Comment by JD Wang (JDWUP) - Thursday, 20 August 2020, 18:22 GMT
It is possible to downgrade the package or fix the config without using LiveUSB by using rescue mode or emergency mode (aka single-user mode). rescue mode (and emergency mode) uses sulogin, which does not use PAM, so a broken PAM will not break this sulogin.
Comment by Doug Newgard (Scimmia) - Thursday, 20 August 2020, 18:29 GMT
Except, emixam and aviallon, your issue is totally different from this ticket. You're hijacking this for your own issue, which is not a bug. Ignore pacman at your own peril.
Comment by Doug Newgard (Scimmia) - Thursday, 20 August 2020, 18:33 GMT



Fair warning for everyone: continued hijacking will result in accounts being disabled.


Comment by Antoine Viallon (aviallon) - Friday, 21 August 2020, 14:19 GMT
@Scimmia why is this hijacking ? I clearly have the issue mentioned (and confirmed it by fixing it). And I did not ignore pacman's pacnew files. But I am (clearly) not a PAM expert, so I don't always know what each config line does.
I don't know how this could have been avoided... perhaps something like a merge tool for important config files, built into pacman, would be cool :)

@JDWUP thank you very much for the rescue mode hint, it saved my day.
Comment by Doug Newgard (Scimmia) - Friday, 21 August 2020, 14:45 GMT
Because this is NOT about the modified configs and pam_tally*. That ticket is  FS#67641 
Comment by François Vaux (madx) - Saturday, 22 August 2020, 23:37 GMT
I've got bitten by this bug as well.
I had a `$HOME/.pam_environment` file. Once I removed it everything worked correctly again.
I was able to login through lxdm but had no dbus server, no user systemd, no pulseaudio, etc.

That `.pam_environment` file was recommended by the SSH-agent wiki page: https://wiki.archlinux.org/index.php/SSH_keys#Start_ssh-agent_with_systemd_user
I reverted to setting that variable in my bash config until what has to be done is a bit more clear
Comment by Husi Susi (HusiSusi) - Monday, 24 August 2020, 08:31 GMT
same issue here. After downgrade to PAM 1.3.x works again!
I don't know if that's important, but I am using old Kernel 4.15.8-1-ARCH.
Comment by Josef Mutzenbacher (Joe2020) - Monday, 24 August 2020, 12:10 GMT
similar issues here. ssh, passwd and sudo affected. ssh with key still works! Fun fact: A raspberry pie running archlinuxarm is affected, too. This bug is a real PITA because it likely results in having no (root) access to a host, at least if you don't have physical access to it.
Comment by Husi Susi (HusiSusi) - Monday, 24 August 2020, 12:59 GMT
interesting, on one of server I have PAM 1.4 and there is no issue!
Comment by Jed Brown (jedbrown) - Thursday, 27 August 2020, 17:53 GMT
~/.pam_environment is also in the GnuPG page (https://wiki.archlinux.org/index.php/GnuPG#Set_SSH_AUTH_SOCK) and if one selects the text and `xsel -o > .pam_environment`, they'll be missing the trailing newline, which currently locks one out. Being unable to log in/needing to use recovery media (if one doesn't have a "clean" login-capable backup account) is about the most severe breakage short of data corruption, so I think "low" severity is an understatement.
Comment by Christopher Snowhill (kode54) - Thursday, 27 August 2020, 22:59 GMT
Assuming you didn't inflict the same damage upon your root account, and still have access to that. Still, having to log directly into root is problematic.
Comment by loqs (loqs) - Thursday, 27 August 2020, 23:27 GMT
There does not appear to be an upstream bug report at [1] about this issue.
Edit:
Reverting [2] and I can no longer reproduce the issue.

[1] https://github.com/linux-pam/linux-pam/issues
[2] https://github.com/linux-pam/linux-pam/commit/563d21d6dbb6d64613919ccb1cc939bae546baab
Edit2:
https://github.com/linux-pam/linux-pam/issues/263
Comment by Doug Newgard (Scimmia) - Saturday, 29 August 2020, 16:47 GMT
Has anyone bothered reporting this upstream?
Comment by loqs (loqs) - Saturday, 29 August 2020, 17:05 GMT
https://github.com/linux-pam/linux-pam/issues/263
Comment by Doug Newgard (Scimmia) - Saturday, 29 August 2020, 17:18 GMT
Oh, I missed your edits. Sorry.
Comment by Shay G (Tharbad) - Saturday, 29 August 2020, 21:32 GMT
Please note: I was unable to use sudo before downgrading to the versions noted the bug desc.
Will report in git.
Comment by loqs (loqs) - Sunday, 13 September 2020, 03:49 GMT
While waiting for a response from upstream reverting 563d21d6dbb6d64613919ccb1cc939bae546baab restores the old behavior.
   PKGBUILD.diff (8 KiB)
Comment by loqs (loqs) - Wednesday, 04 November 2020, 17:03 GMT
Fixed by [1].

[1] https://github.com/linux-pam/linux-pam/commit/12824dd648b0668968231044ed805d1f3b212d7e

Loading...