a/website
1
2
Fork 1
Code Issues Pull requests Projects Releases Wiki Activity

Plasma 6 Fingerprint Bug
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Details

Browse source
This commit is contained in:
Anthony Wang 2024-03-19 21:15:14 -04:00
parent d265c902ec
commit 31fcb9c541
Signed by: a
SSH key fingerprint: SHA256:B5ADfMCqd2M7d/jtXDoihAV/yfXOAbWWri9+GdCN4hQ
1 changed files with 55 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
content/posts/plasma-6-fingerprint-bug.md Normal file
View file

@ -0,0 +1,55 @@
---
title: "Plasma 6 Fingerprint Bug"
date: 2024-03-19T20:33:11-04:00
description: "Figuring out why the KDE Plasma 6 lockscreen is sometimes missing fingerprint login"
type: "post"
tags: ["plasma", "systemd", "linux", "bug"]
---
KDE released Plasma 6 a few weeks ago and it's extremely awesome and also quite buggy. One of the most annoying bugs has been that the lockscreen is sometimes missing the fingerprint login option after resuming from sleep, so I have to type in my password instead. Of course there's the big question about the security of fingerprint login, but I think it's more likely for someone to shoulder surf me rather than knock me unconscious and tap my finger to the sensor. Also, fingerprint login is more convenient. Anyways, I'm just going to ignore that question and focus on this bug instead.
While debugging this, the first main obstacle I ran into is that the KDE's PAM configuration doesn't reset `pam_faillock` after a successful fingerprint login, which has been reported [here](https://bugs.kde.org/show_bug.cgi?id=483130). Basically, whenever you log in with your fingerprint, it gets counted as a failed login anyways and after three tries, you get locked out! The fix is also included in that bug report and just requires adding this to the bottom of the `auth` section in `/etc/pam.d/kde-fingerprint`:
```
auth required pam_faillock.so authsucc
```
Once I got that out of the way, I enabled `debug=on` for `pam_fprintd` (a PAM module to use the fingerprint reader for authentication) to see debug messages for it in the system journal. After triggering the bug and checking the journal with `journalctl -xe`, I found a suspicious line:
```
Mar 19 20:27:53 ThinkPad-X1-Yoga-Gen-6 kscreenlocker_greet[14561]: pam_fprintd(kde-fingerprint:auth): Using device (null) (out of 0 devices)
```
Whoa! There's the problem! `pam_fprintd` is not detecting my laptop fingerprint reader at all. Furthermore, this line is located very early in the wake-up process, when some USB devices haven't been initialized yet!
`lsusb` says that my fingerprint reader has ID `06cb:00fc`, and sure enough, the lines for that are located after the `pam_fprintd` line:
```
Mar 19 20:27:53 ThinkPad-X1-Yoga-Gen-6 kernel: usb 3-3: new full-speed USB device number 117 using xhci_hcd
Mar 19 20:27:53 ThinkPad-X1-Yoga-Gen-6 kernel: usb 3-3: New USB device found, idVendor=06cb, idProduct=00fc, bcdDevice= 0.00
Mar 19 20:27:53 ThinkPad-X1-Yoga-Gen-6 kernel: usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=1
Mar 19 20:27:53 ThinkPad-X1-Yoga-Gen-6 kernel: usb 3-3: SerialNumber: f88de24e63f0
```
This is progress. `pam_fprintd` starts the systemd service `fprintd.service`, so I just need to make this service start after the fingerprint device is initialized. Fortunately, this is doable with systemd but a bit complicated. First, create a udev rule for the device in `/etc/udev/rules.d/69-fingerprint.rules`
```
ATTRS{idVendor}=="06cb", ATTRS{idProduct}=="00fc", SYMLINK="fingerprint", TAG+="systemd"
```
Next, reload udev rules with `sudo udevadm control --reload-rules && sudo udevadm trigger`. Now create an override file for `fprintd.service` using `sudo systemctl edit fprintd.service` and paste in this stuff:
```
[Unit]
After=suspend.target dev-fingerprint.device
Requires=dev-fingerprint.device
```
The `suspend.target` is important because the `dev-fingerprint.device` seems to initially be active right after the wake-up starts, but then gets deactivated and reactivated during wake-up. Thus, we have to wait until after the wake-up finishes, then wait for `dev-fingerprint.device` to be active.
So, to recap, the bug actually has nothing to do with KDE Plasma. I guess it's an `fprintd` problem since maybe it should wait a bit until the USB devices are all initialized? I'm not sure. The only reason I ran into this bug is because previously, Plasma required pressing enter first to show the fingerprint login prompt, but in Plasma 6 is immediately shows the fingerprint login prompt. This causes a race condition with USB device initialization, so the bug doesn't always happen if the USB devices win the race.
Another potential problem is that `fprintd` waits around 30 seconds after a successful login before quitting, so sleeping and waking up and sleeping and waking up can cause the bug to reappear during the second wake-up, but I don't think I'd ever run into this corner case except while debugging this bug. When debugging, I had to manually run `sudo killall fprintd` between sleep-wake up tests.
If you managed to reach the end of this post and understood everything, congratulations, you deserve a bowl of [Biángbiáng noodles](https://functional.cafe/@loke/112120713973565564)!