Hello,

I was hoping that someone can help me understand how the recent version of kscreenlocker works and how it interacts with PAM.

The problem: I have a PC that doesn't contain any sensitive data and its screen is only locked to prevent casual strangers from using it. In other words: I don't care if someone tries to brute-force its password typing it while the screen is locked. At the same time making typos while entering the password (or because the keyboard layout was wrong, or Caps was active) makes it really inconvenient to wait 2-3 seconds for the next attempt.

Thus, fully understanding the consequences of making the failed login attempt timeout 0, I still want to make it so for the above reasons. Once again, this PC does not store any sensitive data and the security there was intentionally made very basic

I've already added nodelay option to the PAM configuration (for pam_unix.so and pam_faillock.so modules) in system-auth file. When trying terminal login or in SDDM, everything is fine - no delay between the login attempts. However, it's not the case for kscreenlocker

Previously it didn't respect PAM and had its own internal hard-coded timer set to 3s. It was possible to patch the source, build, re-install and thus disable the timeout.

The problem is that that version is not compatible with the latest Plasma anymore and the latest version of the code doesn't seem to have that timeout hard-coded anywhere. Yet it still has 3s delay between login attempts.

Is anyone knowledgeable about the code base of kscreenlocker and where that delay could come from?

as usual, the mystery was solved right after asking the question...

If anyone has the same problem and is interested in the solution (at least in Arch Linux, but I believe the same is applicable elsewhere):

- Digging the source code of kscreenlocker revealed that it uses "kde" PAM policy, which relies on system-login and system-auth. Those have already been updated with "nodelay" option (see the original post) so no issues with that part
- kscreenlocker loads current theme's QML to draw and manage the UI
- running it from Konsole and checking its stdout showed the file that is loaded (in my case "/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml")
- that file contained "graceLockTimer" set to 3000. Changing it to 0 almost solved my issue
- the above mentioned theme also uses an animation on rejecting a password (RejectPasswordAnimation) which by default took 600ms
- tracking down its definition ("/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/animation/RejectPasswordPathAnimation.qml") allowed to adjust the animation time (200ms was enough to me, but could be set to 1ms to remove it completely)

The only problem is that these are system files, so most likely they will be rewritten on the next update by the package manager. On ArchLinux I was able to edit "/etc/pacman.conf" to add these 2 files to "NoUpgrade" list. May be a similar thing can be done with apt, yum and other managers..

Clone the Breeze desktop theme, modify and rename it, then have it installed locally instead of system wide. Then, any upgrades will not have any effect, and they can be shared to other systems.

https://develop.kde.org/docs/extend/pla ... uickstart/

You shouldn't have to block a package upgrade for this sort of thing.