Proper PAM Configuration for Howdy w/ Kscreenlocker?

I’ve installed and configured Howdy, a Windows Hello style facial recognition system on my KDE machine. I’ve added Howdy as a sufficient auth in both /etc/pam.d/system-local-login for SDDM [Update: See below] and in /etc/pam.d/kde for kscreenlocker. Within kscreenlocker, I can press the login button without entering a password, and it appropriately prompts Howdy to kick into action and log me in (IR blasters start, camera LED comes comes). When I do use a password however, Howdy is still activated and performing auth (as far as I can tell). At best this results in an unnecessary delay when logging in with a typed password, but at worst, I can be locked out of my machine if Howdy fails multiple times even when the password is correct. [Update: Howdy still performing auth is PAM functioning as intended (see my solution post below). Being locked out is still an issue however.]

While it would be great if I could get rid of the delay of Howdy activating, I can understand why it might happen in terms of the authentication process hitting “evaluate Howdy” before it hits “evaluate password”. The locking out is beyond me however, because while my understanding of PAM is still somewhat elementary, I thought a failure of a sufficient module would be ignored and the login responsibility would continue down the chain to other modules, like the password evaluation.

Any ideas?

/etc/pam.d/kde:

#%PAM-1.0

auth            sufficient      pam_python.so /lib/security/howdy/pam.py
auth            include         system-login
account         include         system-login
password        include         system-login
session         include         system-login

In terms of Howdy setup, I had to add read and execute permissions for all users to /lib/security/howdy for kscreenlocker to recognize/use Howdy and I’ve set no_confirmation = true in the Howdy config, both after reading some GitHub issues about that being necessary for kscreenlocker/SDDM. I also have a laptop + dock setup, so instead of pointing howdy to a one camera directly, I’ve used a udev rule to dynamically symlink my two cameras to /dev/videohowdy. The udev rule + the cameras have all been tested, and as I said, I can successfully login using Howdy.

Not exactly the same, may not even be worth mentioning but…

I use a solokey for login i added auth required pam_u2f.so directly to the SDDM file in etc/pam.d rather than use the system-local-login file.

As you can see i use required rather than sufficient as it’s 2fa key but thought i’d mention it anyway as none of the guides i used mentioned system-local-login. As I understand you are correct about the sufficient being at the top, this matters less for me as I’m forcing the key/password at all times.

Of course this limits the keys use to the login screen so i need to add the line to sudo and other things if i want (i remove it from sudo when experimenting so i can login tty and undo errors).

There is also some delay when using my key. I put it down to the way pam paths work and the cryptographic challenge response.

I hadn’t actually played with my SDDM login a ton just because I don’t reboot super often, but I actually didn’t have it working there. /etc/pam.d/sddm includes system-login directly, not system-local-login so my change was having no effect. I’ve moved my howdy line into sddm and now Howdy activates there too as expected… but it still locks me out even when there is a correct password, so I dropped to TTY and disabled it on SDDM for now.

Thanks for the confirmation.

Did a bit more reading and yes, PAM always checks auth mechanisms sequentially, so when I put my password in and hit enter, firstly Howdy is going to be activated, then if it fails, the password check will occur. No way to dynamically skip Howdy if I’ve input a password, the “solution” there would just be to have the password evaluated before Howdy and then have the inverse behavior; whenever I wanted to use Howdy I’d have to wait for the password to fail first. For security reasons I won’t be going down that route, I’ll probably just reduce the Howdy timeout time.

I’m pretty confident in my PAM configurations now, so I’m guessing in the cases where I get locked out, Howdy might not be denying auth properly, and the auth process is being ended prematurely instead of continuing down the chain (to password). As this would be a Howdy issue and not specific to my Manjaro setup, I’ll consider this post solved and perhaps move the conversation over to the Howdy GitHub.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.