Weird sddm behavior on wrong password

[u/winslowsoren]

Upon inputting a wrong password sddm would repeatly reattempt that wrong password until it is locked out by pam(I discovered this via journals), each failed attempt will cause it to empty the input bar so I have to wait until it is locked by pam to input a new password, this is rather a strange behaviour, do you have any idea how to debug this/ what might be causing the issue?

[u/winslowsoren]

My friend has debugged the whole callchain, it is an issue lying both within the code logic in systemd's PAM and sddm/ly/probably more dm, a fix would require a lot of changes on upstream, guess I'll leave it as this for now

sddm/ly/probably other DMs: if PAM modules is requesting a prompt "with echo", return username, otherwise pass password to the next module

systemd-homed's PAM module: wrong auth attempt result in retry within itself instead of telling PAM to fail like pam_unix 

This also cannot be fixed with PAM module parameter as 5 retries is written as a constant in systemd-homed's code (Yes, they literally write if(++n_attempts >= 5) with 5 being chosen arbitrarily)

Combining those logic together creates this bug

Update: GDM seems to be free of this bug, SDDM has the worst behavior as it will repeatedly clear the inputs, ly result in an abnormally long wait time on failed auth

Update: I've inquired a systemd dev and he said that this is fundamentally  due to a design flaw of systemd-homed https://github.com/systemd/systemd/blob/main/src/home/pam_systemd_home.c#L561 But sddm/ly/...'s behavior is still wrong

I'll probably open a pull request/issue later, for now GDM works the best for me

[u/archover]

Problem can be worked around by a reboot, and correct password entry.

The lockout after three invalid attempts is a security feature. Unsure beyond that. HTH.

Good day.

[u/winslowsoren → u/archover]

That is hardly a solution at all, a reboot is not actually needed and I can reattempt after "sddm realized that it has failed". Of course this is a security feature but it is this rather annoying behavior that I am trying to solve 

[u/archover → u/winslowsoren]

Per my checking, sddm appears innocent. It's the faillock program and pam_fallback. https://man.archlinux.org/man/faillock.8.en

I can only relate my experience being locked out. Wait like 10m or reboot. I usually choose the latter, and that solution is proven to work. I'm happy with the standard handling of three invalid tries.

I'm a sddm user for both Plasma and Cinnamon - no issue like you relate. Maybe file a bug report, and if so, please link.

In any case, use your judgement and approach it the way you want.

Good day.

[u/winslowsoren → u/archover]

No I don't think you get it... It is not faillock, it is PAM fail, my PAM is working correctly as intended, the issue here is that sddm is reattempting wrong password until it gets a fail from PAM, by appearance it is like sddm is actively clearing your password on input after a failed auth three times( and by log, it failed pam three times)

[u/archover → u/winslowsoren]

I will try reproducing.

Ok, tried three invalid login attempts. The sddm DM dialog box just clears the pw after each bad entry. For the forth correct login, the same happens. IIRC, this is the behavior I recall. Clicking the little red icon shuts the system down. If you didn't say otherwise, it would seem to me that faillock and pam is driving this behavior. Sounds like you know otherwise.

Reference: Plasma + sddm + Intel Thinkpad + current linux kernel.

Good day.

[u/winslowsoren → u/archover]

But that is my problem... I have no idea how to reproduce or to debug it, I don't have any config on sddm beside a theme and enabling Wayland (Which has no effect on the problem), and tracing on log only shows me this reattempting auth behavior 

[u/archover → u/winslowsoren]

this might help: https://bbs.archlinux.org/viewtopic.php?id=258321

My log shows:

Dec 28 15:52:51 T480.CRU217.local sddm-helper[826]: pam_unix(sddm:session): session closed for user redd
Dec 28 15:52:57 T480.CRU217.local unix_chkpwd[3038]: password check failed for user (redd)
Dec 28 15:52:57 T480.CRU217.local sddm-helper[3036]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=redd
Dec 28 15:53:03 T480.CRU217.local unix_chkpwd[3041]: password check failed for user (redd)
Dec 28 15:53:03 T480.CRU217.local sddm-helper[3039]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=redd
Dec 28 15:53:07 T480.CRU217.local unix_chkpwd[3044]: password check failed for user (redd)
Dec 28 15:53:07 T480.CRU217.local sddm-helper[3042]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=redd
Dec 28 15:53:07 T480.CRU217.local sddm-helper[3042]: pam_faillock(sddm:auth): Consecutive login failures for user redd account temporarily locked
Dec 28 15:53:11 T480.CRU217.local unix_chkpwd[3052]: password check failed for user (redd)
Dec 28 15:53:11 T480.CRU217.local sddm-helper[3050]: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=redd
Dec 28 15:55:28 T480.CRU217.local systemd[1]: Stopping Session 2 of User redd...
Dec 28 15:55:28 T480.CRU217.local systemd[1]: Stopped Session 2 of User redd.
Dec 28 15:55:28 T480.CRU217.local (sd-pam)[834]: pam_unix(systemd-user:session): session closed for user redd

Good day.

[u/winslowsoren → u/archover]

In your log, you manually had three incorrect attempt right? 

In my problem sddm will trigger all those incorrect attempt to PAM after you have tried to login with wrong password once

Logging in on a TTY doesn't replicate issue nor does su/sudo, so it can't be a PAM issue

SELinux is on permissive and on test has no effect on the issue

Here is my log, all the PAM failure happened within the same second...

I suspect it has something to do with my user being systemd-homed, but I can't find any non-standard configuration

Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: pam_systemd_home(sddm:auth): Failed to acquire home for user winslow: Password for home winslow is incorrect or not sufficient for authentication. Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Preparing to converse... Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Conversation with 1 messages Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Preparing to converse... Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Conversation with 1 messages Dec 28 19:21:22 navi.client.winslow.cloud sddm[1080]: Authentication error: SDDM::Auth::ERROR_AUTHENTICATION "Password incorrect or not sufficient for authentication of user winslow." Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: Information Message received from daemon:  "Password incorrect or not sufficient for authentication of user winslow." Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: Message received from daemon: LoginFailed Dec 28 19:21:22 navi.client.winslow.cloud kernel: audit: type=1400 audit(1735442482.364:2418): avc:  denied  { ioctl } for  pid=836 comm="systemd-homed" path="/home/winslow.homedir" dev="dm-1" ino=256 ioctlcm d=0x9412 scontext=system_u:system_r:systemd_homed_t:s0-s15:c0.c2047 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir permissive=1 Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Preparing to converse... Dec 28 19:21:22 navi.client.winslow.cloud sddm-helper[3115]: [PAM] Conversation with 1 messages Dec 28 19:21:22 navi.client.winslow.cloud sddm[1080]: Authentication error: SDDM::Auth::ERROR_AUTHENTICATION "Too many unsuccessful login attempts for user winslow, refusing." Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: file:///usr/share/sddm/themes/Commonality/Main.qml:47: ReferenceError: errorMessage is not defined Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: Information Message received from daemon:  "Too many unsuccessful login attempts for user winslow, refusing." Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: Message received from daemon: LoginFailed Dec 28 19:21:22 navi.client.winslow.cloud sddm-greeter-qt6[3020]: file:///usr/share/sddm/themes/Commonality/Main.qml:47: ReferenceError: errorMessage is not defined Dec 28 19:21:22 navi.client.winslow.cloud kernel: audit: type=1400 audit(1735442482.370:2419): avc:  denied  { connectto } for  pid=3191 comm="unix_chkpwd" path="/systemd/userdb/io.systemd.DynamicUser" sconte xt=system_u:system_r:chkpwd_t:s0-s15:c0.c2047 tcontext=system_u:system_r:kernel_t:s15:c0.c2047 tclass=unix_stream_socket permissive=1 Dec 28 19:21:22 navi.client.winslow.cloud kernel: audit: type=1400 audit(1735442482.370:2420): avc:  denied  { write } for  pid=3191 comm="unix_chkpwd" name="io.systemd.Home" dev="tmpfs" ino=2959 scontext=sys tem_u:system_r:chkpwd_t:s0-s15:c0.c2047 tcontext=system_u:object_r:systemd_homed_runtime_t:s0 tclass=sock_file permissive=1

[u/winslowsoren → u/winslowsoren]

Tried switching to ly as display manager, the behavior fits expectation now but I found that the issue still persists in log, so it should be a systemd problem

pam_systemd_home: Conversation function failed conversation error

[u/winslowsoren → u/winslowsoren]

My friend has debugged the whole callchain, it is an issue lying both within the code logic in systemd's PAM and sddm/ly/probably more dm, a fix would require a lot of changes on upstream, guess I'll leave it as this for now

sddm/ly/probably other DMs: if PAM modules is requesting a prompt "with echo", return username, otherwise pass password to the next module

systemd-homed's PAM module: wrong auth attempt result in retry within itself instead of telling PAM to fail like pam_unix 

This also cannot be fixed with PAM module parameter as 5 retries is written as a constant in systemd-homed's code (Yes, they literally write if(++n_attempts >= 5) with 5 being chosen arbitrarily)

Combining those logic together creates this bug

Update: GDM seems to be free of this bug, SDDM has the worst behavior as it will repeatedly clear the inputs, ly result in an abnormally long wait time on failed auth

Update: I've inquired a systemd dev and he said that this is fundamentally  due to a design flaw of systemd-homed https://github.com/systemd/systemd/blob/main/src/home/pam_systemd_home.c#L561 But sddm/ly/...'s behavior is still wrong