https://bugs.kde.org/show_bug.cgi?id=438099
Bug ID: 438099
Summary: Endless loop when using PAM module pam_systemd_home.so
after wrong password
Product: kscreenlocker
Version: unspecified
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: r...@posteo.de
CC: bhus...@gmail.com
Target Milestone: ---
Created attachment 139007
--> https://bugs.kde.org/attachment.cgi?id=139007&action=edit
Working but but probably no where near correct fix - beware!
SUMMARY
Trying to unlock screen as a user created with systemd-homed (or more specific:
homectl) results in an loop when using wrong password. kscreenlocker/kcheckpass
will try to authenticate forever.
I can see this behavior in current Arch Linux and Fedora 34.
STEPS TO REPRODUCE
1. Get current Arch Linux installation or VM with KDE. (Systemd-homed is
ready-to-use in Arch, but not in Fedora 34.)
2. Create user as root: homectl create testuser --storage=directory --uid=12345
Setting the UID here as users with UIDs over 60000 (which are otherwise
chosen by default) are not shown in SDDM.
3. Log in SDDM as this new user (X11/Wayland-Session doesn't matter)
4. Switch to TTY and as root run: journalctl -f
3. Switch back, lock screen and try to unlock but with a wrong password.
4. Switch to TTY to watch error messages. Kill kcheckpass to end loop and use
"loginctl unlock-session $(session)" to unlock.
OBSERVED RESULT
The endless loop will hit the systemd-homed authentication rate limit on first
try with a wrong password (see "homectl inspect testuser"). kscreenlocker won't
allow another authentication attempt.
EXPECTED RESULT
Another authentication attempt with kscreenlocker acquiring new user password.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Updated Arch Linux or Fedora 34
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
It seems that the PAM module pam_systemd_home.so tries to reacquire a new
password after initial failed attempt and continues the PAM-conversation. But
kcheckpass continues (without actually reacquiring a new PW from user) where it
should probably bail.
The whole thing can be debugged with "kcheckpass_test --direct".
I found that the attached patch fixes the problem for me. But I can't in any
way assess if this is a proper solution.
--
You are receiving this mail because:
You are watching all bug changes.
