SUMMARY When auto lock screen,the finger unlock is broken (manual lock works) STEPS TO REPRODUCE 1. wait for the auto screen lock 2. try unlock with finger unlock OBSERVED RESULT no "or place finger in reader" EXPECTED RESULT have "or place finger in reader",and can be unlock with finger SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.12.35-1-lts (64-bit) Graphics Platform: Wayland Processors: 18 × Intel® Core™ Ultra 5 125H Memory: 32 GiB of RAM (30.8 GiB usable) Graphics Processor: Mesa Intel® Arc ADDITIONAL INFORMATION alhsk@MiWiFi-RA72-srv ~ [1]> sudo fprintd-list alhsk found 1 devices Device at /net/reactivated/Fprint/Device/0 Using device /net/reactivated/Fprint/Device/0 Fingerprints for user alhsk on Goodix MOC Fingerprint Sensor (press): - #0: right-index-finger hardware: Bus 003 Device 003: ID 27c6:689a Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
I'm able to reproduce this in git-master, but only if I wait for a while after the screen locks. If I let it lock automatically, and unlock it right away, fingerprint unlock works as usual. This could be a variant of bug 458130. Are you able to reproduce this as soon as the screen locks?
(In reply to TraceyC from comment #1) > I'm able to reproduce this in git-master, but only if I wait for a while > after the screen locks. If I let it lock automatically, and unlock it right > away, fingerprint unlock works as usual. This could be a variant of bug > 458130. > > Are you able to reproduce this as soon as the screen locks?我能够在 git-master > 中重现这一点,但前提是我在屏幕锁定后等待一段时间。如果我让它自动锁定并立即解锁,指纹解锁会照常工作。这可能是 bug 458130 的变体。 > > 您能否在屏幕锁定后立即重现此内容? Yes Sorry,I replay too late
Thanks for letting us know. I'll keep this open in case someone else is able to reproduce it.
When you have the unlock prompt that has no fingerprint text, if you press Enter, can you unlock with the fingerprint?
(In reply to TraceyC from comment #4) > When you have the unlock prompt that has no fingerprint text, if you press > Enter, can you unlock with the fingerprint? NO,it didn't work at all
(In reply to alhsk from comment #5) > NO,it didn't work at all Thanks for clarifying. I'll let the plasmashell developers take it from here.
Correcting priority, since this is not a feature request, it's a bug
I can reproduce this on git master too.
I'm now also seeing this on git-master
I can confirm this as well on latest Plasma (6.4.5, Arch). The label "press finger on sensor" sometimes activates, and sometimes deactivates, usually after suspend. I'm fairly sure this didn't happen before (6.3.x), although I'm not sure. I'd be cool if someone cranked up the importance of this bug, or indicated where and what component are responsible of handling the fingerprint stuff so we can start looking into it.
As another data point, I'm seeing this on git master too. My laptop doesn't have a fingerprint scanner or card reader, but if I leave it idle for long enough and then wake, both messages are shown briefly then disappear.
aaaalright, so I compiled the _allegedly_ buggy component (kscreenlocker - plasma 6.4.5.x), ran it in debug mode and I believe I found what appears to be causing the issue. I don't know if this is hardware-dependent. 1. When the computer (laptop) goes to sleep, the BIOS sometimes likes to reset the fingerprint device, and it's enumerated again by fprintd upon wake up (and registered as a new fprint "Device") 2. This usually happens when closing the lid; and not when manually suspending the computer (be it with KDE taskbar menu, Plasma Search's shortcuts or systemd's utilities). I suspect this is caused by either the BIOS or a bug in fprintd. 3. When the computer wakes up, kscreenlocker tries to "talk" again to the previous old device, but it miserably fails because at this point fprintd has already registered another device (this can be seen with `busctl tree net.reactivated.Fprint` - there should ideally be just 1 device, not 2) 4. The old fprintd device will simply stop working and even commands such as `fprintd-verify` will fail 5. Whenever this happens, the kscreenlock process will hang for a few secs before it finally exists. I don't thinks causes the bug, but it _might_ cause a bug if I lock/unlock my computer very quickly. I suspect this happens because kscreenlocker is waiting for the useless fprint "Device" to respond successfully or something. I worked this around doing the following: 1. Edit fprintd's systemd unit file and add `TimeoutStopSec=1` to immediately kill the (now useless) fprintd service after startup 2. Create an udev rule that automatically restarts the useless fprintd daemon whenever my *VERY SPECIFIC* fingerprint device is enumerated again: `/etc/udev/rules.d/99-fprintd.rules`: "ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="06cb", ATTR{idProduct}=="00fc", RUN+="/bin/systemctl restart fprintd" My suggestion: have KDE/Plasma automatically restart the fprintd service if it returns an invalid error code (9), or at the very least indicate this on the lockscreen, e.g. something such as "fingerprint sensor disabled due to buggy driver". fprintd logs: ``` Sep 24 14:09:49 xxx fprintd[12371]: Authorization denied to :1.337 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed Sep 24 14:10:06 xxx fprintd[12371]: Authorization denied to :1.341 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed Sep 24 14:10:17 xxx fprintd[12371]: Authorization denied to :1.344 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed Sep 24 14:11:13 xxx systemd[1]: fprintd.service: State 'stop-sigterm' timed out. Killing. ``` `fprintd-verify` output: ``` Using device /net/reactivated/Fprint/Device/1 failed to claim device: GDBus.Error:net.reactivated.Fprint.Error.AlreadyInUse: Device was already claimed ``` kscreenlocker (I added a few debug messages to the source), but you can see it fails to talk to fprintd, and hence it disables the fingerprint option. I am still able to manually unlock and that's why `Unlocked` is printed at the end: ``` kscreenlocker_greet: Greeter is starting up. kscreenlocker_greet: Greeter is running in testing mode kscreenlocker_greet: Testing mode enabled: true kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started kscreenlocker_greet: [PAM worker kde] start: successfully started Locked at 1758743384 kscreenlocker_greet: PamAuthenticators: starting authenticators kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-smartcard duration: 2017873 kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-fingerprint duration: 1326118 kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) kscreenlocker_greet: [PAM worker] UNAVAIL/UNKNOWN m_unavailable= true kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 28 (Module is unknown) kscreenlocker_greet: [PAM worker] UNAVAIL/UNKNOWN m_unavailable= true kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business kscreenlocker_greet: [PAM worker] Fail delay function was called, but authentication result was a success! kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 0 (Success) kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business < ... HANGS for some 5-10s before finally exiting ... > kscreenlocker_greet: [PAM worker] PAM_SUCCESS m_unavailable= false kscreenlocker_greet: PamAuthenticators: Success from interactive authenticator kde Unlocked ```
Ah, nevermind :(. Unfortunately, the udev hack doesn't appear to work reliably because the klockscreen component also has some logic that seems flawed. Good thing is that I managed to somehow fix it with the udev hack and by handling some corner cases in klockscreen. I also came up with a reliable way to reproduce this error with current plasma (6.4.5): 1. Restart fprintd service to start with a clean slate (systemctl restart fprintd), or kill fprintd with pkill 2. Lock the screen (at this point, the "(or press your fingerprint)" thing will appear. Do not unlock with fingerprint. 3. Either close the lid or hit the lockscreen suspend button, or do whatever anything t 4. Wake the computer up again. At this point, it appears that no matter what, even if the fprintd service is restarted to make it work again, klockscreen won't "detect" fprintd is up again. So even if the fprintd hack were to be used, klockscreen's auth logic is slightly bugged because it won't retry to use fprintd again. It permanently "thinks" the fprintd thing is dead. I'm a developer, although I have absolutely 0.000% C++/Qt experience whatsoever but I came up with the following patch and it has worked fairly well for me. I must say however, that it appears to increment the PAM faillock count by 2 (this was already an issue for me even without the patches - though vanilla klockscreen only increased the count by 1, so this underlying bug might be caused due to klockscreen triggering a pam error or something). Note to KDE devs: I'm willing to help you fix this issue. ``` diff --git a/greeter/pamauthenticator.cpp b/greeter/pamauthenticator.cpp index 077831d..d5b9963 100644 --- a/greeter/pamauthenticator.cpp +++ b/greeter/pamauthenticator.cpp @@ -132,6 +132,9 @@ int PamWorker::converse(int n, const struct pam_message **msg, struct pam_respon // if there's only the info message, let's predict the prompts too const QString info = QString::fromLocal8Bit(msg[i]->msg); qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Message: Info message: %s", qUtf8Printable(c->m_service), qUtf8Printable(info)); + // If fingerprint device sends info message, it's now available + c->m_unavailable = false; + Q_EMIT c->unavailabilityChanged(c->m_unavailable); Q_EMIT c->infoMessage(info); break; } @@ -159,7 +162,7 @@ PamWorker::~PamWorker() void PamWorker::authenticate() { - if (m_inAuthenticate || m_unavailable) { + if (m_inAuthenticate) { return; } m_inAuthenticate = true; @@ -177,6 +180,8 @@ void PamWorker::authenticate() if (rc == PAM_SUCCESS) { rc = pam_setcred(m_handle, PAM_REFRESH_CRED); /* ignore errors on refresh credentials. If this did not work we use the old ones. */ + m_unavailable = false; + Q_EMIT unavailabilityChanged(m_unavailable); Q_EMIT succeeded(); } else if (rc == PAM_AUTHINFO_UNAVAIL || rc == PAM_MODULE_UNKNOWN) { m_unavailable = true; @@ -309,7 +314,7 @@ bool PamAuthenticator::isBusy() const bool PamAuthenticator::isAvailable() const { - return m_inAuthentication && !m_unavailable; + return !m_unavailable; } PamAuthenticator::NoninteractiveAuthenticatorTypes PamAuthenticator::authenticatorType() const diff --git a/greeter/pamauthenticators.cpp b/greeter/pamauthenticators.cpp index e9e925a..f1f6348 100644 --- a/greeter/pamauthenticators.cpp +++ b/greeter/pamauthenticators.cpp @@ -18,6 +18,7 @@ struct PamAuthenticators::Private { AuthenticatorsState state = AuthenticatorsState::Idle; bool graceLocked = false; bool hadPrompt = false; + bool interactiveCancelledByFingerprint = false; void recomputeNoninteractiveAuthenticationTypes() { @@ -51,7 +52,11 @@ PamAuthenticators::PamAuthenticators(std::unique_ptr<PamAuthenticator> &&interac qCDebug(KSCREENLOCKER_GREET) << "PamAuthenticators: Failure from interactive authenticator" << qUtf8Printable(d->interactive->service()); setState(AuthenticatorsState::Idle); d->cancelNoninteractive(); - Q_EMIT failed(PamAuthenticator::NoninteractiveAuthenticatorType::None, d->interactive.get()); + // Don't emit failed if interactive was cancelled due to fingerprint becoming available + if (!d->interactiveCancelledByFingerprint) { + Q_EMIT failed(PamAuthenticator::NoninteractiveAuthenticatorType::None, d->interactive.get()); + } + d->interactiveCancelledByFingerprint = false; }); connect(d->interactive.get(), &PamAuthenticator::loginFailedDelayStarted, this, [this](const uint uSecDelay) noexcept -> void { qCDebug(KSCREENLOCKER_GREET) << "PamAuthenticators: Delay started on login failure for interactive authenticator" << qUtf8Printable(d->interactive->service()) @@ -83,6 +88,8 @@ PamAuthenticators::PamAuthenticators(std::unique_ptr<PamAuthenticator> &&interac d->hadPrompt = true; Q_EMIT hadPromptChanged(); } + // Mark that interactive will be cancelled due to fingerprint becoming available + d->interactiveCancelledByFingerprint = true; qCDebug(KSCREENLOCKER_GREET) << "PamAuthenticators: Info message from non-interactive authenticator" << qUtf8Printable(noninteractive->service()); Q_EMIT noninteractiveInfo(noninteractive->authenticatorType(), noninteractive.get()); }); ```
(In reply to Caballo Juan from comment #13) > I'm a developer, although I have absolutely 0.000% C++/Qt experience > whatsoever but I came up with the following patch and it has worked fairly > well for me. You can submit a merge request to the relevant project on Gitlab, where it will be reviewed by the devs. (I'm not a KDE dev myself, so can't help you with the details.)
Yes, please do submit that on invent.kde.org!
(In reply to Nate Graham from comment #15) > Yes, please do submit that on invent.kde.org! Sure! However, this patch doesn't fix everything as I mentioned earlier (and it can't). My patch merely allows klockscreen to talk to fprintd if it ever gets restarted. The rest of the problem must be fixed in fprintd (that's why I used an udev rule to forcefully restart it, and thus allow klockscreen to talk to it again). I'll try to get the patch merged anyway, as that should make klockscreeen basically immune to temporary sensor errors. :)
(In reply to Nate Graham from comment #15) > Yes, please do submit that on invent.kde.org! aaaaalright, I just submitted a PR. Feel free to review whenever you get the chance: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/292
I still see this issue in Plasma 6.5.1. In my case, the fingerprint unlocking is not working when I click on "standby" on the lock screen and wake my device afterwards.
in 6.5.1,although there isn't prompt,i still can unlock by fingerprint...
Can anyone test if https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/296 fixes this bug? I can't reproduce with the patch applied.
(In reply to Fushan Wen from comment #20) > Can anyone test if > https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/296 fixes this > bug? I can't reproduce with the patch applied. I tested your branch and I am still able to reproduce the fingerprint issue. I also took a look at your PR and it doesn't appear to address this specific issue but something else (kdeconnect unlocking). The rest of the code still pretty much disables smartcard/fp auth "permanently" whenever PAM returns an error.
(In reply to Caballo Juan from comment #21) > (In reply to Fushan Wen from comment #20) > > Can anyone test if > > https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/296 fixes this > > bug? I can't reproduce with the patch applied. > > I tested your branch and I am still able to reproduce the fingerprint issue. > I also took a look at your PR and it doesn't appear to address this specific > issue but something else (kdeconnect unlocking). The rest of the code still > pretty much disables smartcard/fp auth "permanently" whenever PAM returns an > error. I see. I don't have any smartcard or fingerprint but the screenlocker still shows them for 2 seconds, so it turns out I misread the bugreport.
Git commit 29d01bf74958b96b41d1726b5ff6b133a7a0e402 by David Edmundson. Committed on 02/02/2026 at 15:04. Pushed by davidedmundson into branch 'master'. On successful login exit without completing pending PAM jobs We have an issue that the pam_unix backend will report a failure if we complete the converse method, no matter the error codes returned. If a user logs in with a fingerprint multiple times in quick succession this will lock the user out. Related: bug 484363 M +6 -1 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/29d01bf74958b96b41d1726b5ff6b133a7a0e402
Git commit 51ae1c3d6e615891d03281935a93eed67130b720 by David Edmundson. Committed on 02/02/2026 at 15:25. Pushed by davidedmundson into branch 'Plasma/6.6'. On successful login exit without completing pending PAM jobs We have an issue that the pam_unix backend will report a failure if we complete the converse method, no matter the error codes returned. If a user logs in with a fingerprint multiple times in quick succession this will lock the user out. Related: bug 484363 (cherry picked from commit 29d01bf74958b96b41d1726b5ff6b133a7a0e402) 2bb39ffa On successful login exit without completing pending PAM jobs a52adb1c Apply 1 suggestion(s) to 1 file(s) 84b93423 Apply 1 suggestion(s) to 1 file(s) Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +6 -1 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/51ae1c3d6e615891d03281935a93eed67130b720
(In reply to David Edmundson from comment #24) > Git commit 51ae1c3d6e615891d03281935a93eed67130b720 by David Edmundson. > Committed on 02/02/2026 at 15:25. > Pushed by davidedmundson into branch 'Plasma/6.6'. > I tested the last stuff from kscreenlocker's master branch but the bug still seems to be there. Perhaps this commit addresses some other issue that appears to be unrelated to the fact that the fingerprint auth logic dies/gets corrupted after suspend or after the PAM timeout elapses. I am reopening this bug and attaching some logs. Unfortunately, I don't have the time to fix/rebase the PR I sent a few months ago (I worked on it for a few weeks, but got ignored lol). I'm also attaching my diff at the end of this post with what has, so far, worked for me. BTW, I noticed the following bugs in the latest and greatest in master, so this might help you come up with the right solution as my C++ is very bad: 1. pamauthenticator.cpp @ authenticate(): the current m_unavailable disable logic is extremely buggy as it permanently disables authenticators even if they experience transient errors, and doesn't allow any retry logic to kick in again 2. pamauthenticator.cpp @ `case PAM_TEXT_INFO`: we need to re-enable here the (fingerprint) authenticator, e.g `m_unavailable=false` again if we receive a timeout or a "valid" message from PAM. So far I've noticed PAM usually returns "place your XYZ finger on the fingerprint reader", and "timed out". If we get one of these messages, we need to make the device available again. 3. pamauthenticator.cpp @ authenticate() `if (rc == PAM_AUTHINFO_UNAVAIL || rc == PAM_MODULE_UNKNOWN`: this statement should further check if the FP device was disabled due to a timeout or if it was enabled back again (even if the returned pam_authenticate() returned an error) and if that's the case, reset the nextAttemptAllowed timer and invoke authenticate() again I also noticed that even without any of the above changes (latest master), the password entry field wobbles and indicates "Unlocking failed" shortly after pressing the suspend button. That might be a completely different issue. Logs (latest master) ``` kscreenlocker_greet: Greeter is starting up. kscreenlocker_greet: [PAM worker kde] start: successfully started kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started kscreenlocker_greet: Greeter is running in testing mode kscreenlocker_greet: Testing mode enabled: true Locked at 1770434097 kscreenlocker_greet: PamAuthenticators: starting authenticators kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 28 (Module is unknown) kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-smartcard duration: 1934336 kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde kscreenlocker_greet: [PAM worker kde-fingerprint] Message: Info message: Place your right index finger on the fingerprint reader kscreenlocker_greet: PamAuthenticators: Info message from non-interactive authenticator kde-fingerprint kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator kscreenlocker_greet: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR kscreenlocker_greet: [PAM worker kde] Nested event loop's exit code was not zero, bailing kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 20 (Authentication token manipulation error) kscreenlocker_greet: PamAuthenticators: Delay started on login failure for interactive authenticator kde duration: 1787620 kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-fingerprint duration: 2228651 kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false kscreenlocker_greet: PamAuthenticators: starting authenticators kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business kscreenlocker_greet: [PAM worker] Fail delay function was called, but authentication result was a success! kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 0 (Success) kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business kscreenlocker_greet: PamAuthenticators: Success from interactive authenticator kde Unlocked ``` here's my very rough, 100% not prod-ready diff :P ``` diff --git a/CMakeLists.txt b/CMakeLists.txt index 01613b6a..c033d7ce 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -5,7 +5,7 @@ set(CMAKE_C_STANDARD 99) set(PROJECT_VERSION "6.6.80") set(PROJECT_VERSION_MAJOR 6) -set(PROJECT_DEP_VERSION "6.5.90") +set(PROJECT_DEP_VERSION "6.5.5") //test moment set(QT_MIN_VERSION "6.10.0") set(KF6_MIN_VERSION "6.22.0") diff --git a/greeter/pamauthenticator.cpp b/greeter/pamauthenticator.cpp index 9cbff076..6d002888 100644 --- a/greeter/pamauthenticator.cpp +++ b/greeter/pamauthenticator.cpp @@ -10,6 +10,7 @@ #include <QEventLoop> #include <QMetaMethod> #include <QThread> +#include <QTimer> #include <security/pam_appl.h> #include "kscreenlocker_greet_logging.h" @@ -18,7 +19,7 @@ class PamWorker : public QObject { Q_OBJECT public: - PamWorker(); + PamWorker(PamAuthenticator::NoninteractiveAuthenticatorTypes authenticatorType); ~PamWorker() override; Q_DISABLE_COPY_MOVE(PamWorker) void start(const QString &service, const QString &user); @@ -48,7 +49,9 @@ private: struct pam_conv m_conv; bool m_unavailable = false; + bool m_fingerprintRetry = false; bool m_inAuthenticate = false; + PamAuthenticator::NoninteractiveAuthenticatorTypes m_authenticatorType; std::chrono::steady_clock::time_point m_nextAttemptAllowedTime; int m_result = -1; QString m_service; @@ -134,6 +137,15 @@ int PamWorker::converse(int n, const struct pam_message **msg, struct pam_respon // if there's only the info message, let's predict the prompts too const QString info = QString::fromLocal8Bit(msg[i]->msg); qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Message: Info message: %s", qUtf8Printable(c->m_service), qUtf8Printable(info)); + if (c->m_authenticatorType == PamAuthenticator::NoninteractiveAuthenticatorType::Fingerprint){ + if (info.contains(QStringLiteral("finger on the fingerprint reader")) || + info.contains(QStringLiteral("place your finger on the fingerprint reader")) + ){ + c->m_unavailable = false; + c->m_fingerprintRetry = true; + Q_EMIT c->unavailabilityChanged(c->m_unavailable); + } + } Q_EMIT c->infoMessage(info); break; } @@ -146,9 +158,10 @@ int PamWorker::converse(int n, const struct pam_message **msg, struct pam_respon return PAM_SUCCESS; } -PamWorker::PamWorker() +PamWorker::PamWorker(PamAuthenticator::NoninteractiveAuthenticatorTypes authenticatorType) : QObject(nullptr) , m_conv({&PamWorker::converse, this}) + , m_authenticatorType(authenticatorType) , m_nextAttemptAllowedTime(std::chrono::steady_clock::now()) { } @@ -162,7 +175,7 @@ PamWorker::~PamWorker() void PamWorker::authenticate() { - if (m_inAuthenticate || m_unavailable) { + if (!m_fingerprintRetry && (m_inAuthenticate || m_unavailable)) { return; } else if (std::chrono::steady_clock::now() < m_nextAttemptAllowedTime) { qCCritical(KSCREENLOCKER_GREET, "[PAM worker %s] Authentication attempt too soon. This shouldn't happen!", qUtf8Printable(m_service)); @@ -181,16 +194,28 @@ void PamWorker::authenticate() Q_EMIT busyChanged(false); if (rc == PAM_SUCCESS) { + m_unavailable = false; rc = pam_setcred(m_handle, PAM_REFRESH_CRED); /* ignore errors on refresh credentials. If this did not work we use the old ones. */ Q_EMIT succeeded(); } else if (rc == PAM_AUTHINFO_UNAVAIL || rc == PAM_MODULE_UNKNOWN) { + if (m_fingerprintRetry && m_authenticatorType == PamAuthenticator::NoninteractiveAuthenticatorType::Fingerprint) { + m_unavailable = false; + // reset timer to allow fp retry immediately + m_nextAttemptAllowedTime = std::chrono::steady_clock::now(); + QTimer::singleShot(1, this, &PamWorker::authenticate); + m_inAuthenticate = false; + Q_EMIT inAuthenticateChanged(m_inAuthenticate); + return; + } m_unavailable = true; Q_EMIT unavailabilityChanged(m_unavailable); } else { Q_EMIT failed(); } m_inAuthenticate = false; + m_fingerprintRetry = false; + Q_EMIT inAuthenticateChanged(m_inAuthenticate); } @@ -251,7 +276,7 @@ PamAuthenticator::PamAuthenticator(const QString &service, const QString &user, }) , m_service(service) , m_authenticatorType(types) - , d(new PamWorker) + , d(new PamWorker(types)) { d->moveToThread(&m_thread); ```
That last patch is quite similar to https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/292/diffs I'm mostly ok with landing that, it mostly got blocked because it was lost in the noise from other bugs and CI issues at the time. I also don't get the cancelEmitFailed part of the patch.
(In reply to David Edmundson from comment #26) > That last patch is quite similar to > https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/292/diffs Yeah, it's quite similar as the problem is pretty much in the authenticate() logic. The cancelEmitFailed (which I removed in the latest diff I posted a few comments above) was trying to deal with some weird race condition where an authentication failure was triggered without doing anything before/after suspend Fushan introduced a couple changes some few months ago to deal with this specific problem (it is, however, causing constant authentication failures before/after suspend, at least for me). Point is, I removed that specific cancelEmitFailed stuff because it's completely unrelated to the actual fingerprint issue. The only thing that probably needs more polishing is the part where I simply ignore the existing timer and call authenticate() again after 1ms. right now it works just fine, but I noticed the timer was being set to some ~2.5s. I assume the auth UI is supposed to be disabled for that duration but ehhhh I wanted a quick solution and 1ms just cuts it. BTW, since I can't edit my own messages, I can't fix a small error in the diff I sent. It should be `if (info.contains(QStringLiteral("finger on the fingerprint reader")) || info.contains(QStringLiteral("timed out"))`.
Diffs are better sent in the form of merge requests. Would you be interested in doing that?
Caballo, are you able to submit it formally?
Git commit 1cccd29ca49697b341df4a889c20c84b3cc52965 by David Edmundson. Committed on 02/02/2026 at 15:25. Pushed by davidedmundson into branch 'Plasma/6.5'. On successful login exit without completing pending PAM jobs We have an issue that the pam_unix backend will report a failure if we complete the converse method, no matter the error codes returned. If a user logs in with a fingerprint multiple times in quick succession this will lock the user out. Related: bug 484363 (cherry picked from commit 29d01bf74958b96b41d1726b5ff6b133a7a0e402) 2bb39ffa On successful login exit without completing pending PAM jobs a52adb1c Apply 1 suggestion(s) to 1 file(s) 84b93423 Apply 1 suggestion(s) to 1 file(s) Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +6 -1 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/1cccd29ca49697b341df4a889c20c84b3cc52965
(In reply to Nate Graham from comment #29) > Caballo, are you able to submit it formally? Nope, please see the last comment in reddit. Also, why was this bug marked as resolved? The last commit (1cccd29ca49697b341df4a889c20c84b3cc52965) doesn't really fix this issue at all because the retry logic is still broken