howdy
howdy copied to clipboard
boltgolt
KDE Screenlock error
Hello,
I'm happily using HOWDY in a number of circumstances.
The one linger issue I have is that the KDE screenlocker does not properly seem to use howdy. I'm not sure why. I thought it was initially because the screen locker had some weird PAM configuration, but when I check /var/log/auth.log , it appears as if the issue is something else (howdy does indeed get called.)
The message I get in auth.log is : Jun 1 14:27:54 samiran-G7-7700 [HOWDY]: Attempting facial authentication for user samiran Jun 1 14:27:54 samiran-G7-7700 [HOWDY]: Failure, unknown error1
Not exactly sure what the issue is here, but it happens across two machines (one is my odd multiseat configuration, the other is a standard laptop).
Any help chasing down further info would be appreciated. Howdy works in all contexts otherwise; just not the lockscreen. I almost wonder if device access is not allowed by the context the screenlocker is running in? I tried chmod ugo+rwx on /dev/video0 , but that made no difference.
Thanks,
Sherwin
Searched around for permissions issues.
This command sorta-fixes it : $ sudo chmod a+x /lib/security/howdy/recorders
It appears that you still have to press "enter" at the empty password point at the lock screen, but it will then do a facial verification.
Searched around for permissions issues.
This command sorta-fixes it : $ sudo chmod a+x /lib/security/howdy/recorders
It appears that you still have to press "enter" at the empty password point at the lock screen, but it will then do a facial verification.
Should I add “auth sufficient pam_python.so /lib/security/howdy/pam.py“ to “/etc/pam.d/sddm“ ?
Shouldn't it be considered a permission bug on kscreenlocker side?
I would set the set-user-id bit on kcheckpass instead: sudo chmod u+s /usr/lib/kcheckpass or on ubuntu/debian: sudo chmod u+s /usr/lib/x86_64-linux-gnu/libexec/kcheckpass
so not everyone gets access to howdy's files
Agreed, it is an issue at kscreenlocker. Seems like a good workaround too, but that makes it run with more privileges than it apparently needs.
Okay, I open one so they can have a look. Here is the link: https://bugs.kde.org/show_bug.cgi?id=449577
David Edmundson (from KDE) thinks this is a howdy's bug. Maybe some developer here can check his comment and respond there if you don't agree.
Shouldn't it be considered a permission bug on kscreenlocker side?
There is no reason for any part of kscreenlocker to run as root. We are also planning to drop kcheckpass in the future as an external binary. It only existed for super old non-pam systems.
pam_unix spawns a suid helper to perform reading of /etc/shadow fprintd also has an independent daemon
Given your pam process is spawning a helper anyway howdy can do the same rather than us weakening our userspace level.
Shouldn't it be considered a permission bug on kscreenlocker side?
I would set the set-user-id bit on kcheckpass instead:
sudo chmod u+s /usr/lib/kcheckpassor on ubuntu/debian:sudo chmod u+s /usr/lib/x86_64-linux-gnu/libexec/kcheckpassso not everyone gets access to howdy's files
I upgraded KDE Plasma to 5.25 just now, however I found howdy didn't work again ( because Plasma 5.25 removes kcheckpass )
After upgrading to Plasma 5.25, "sudo chmod u+s /usr/lib/kcheckpass" doesn't work because Plasma 5.25 removes kcheckpass
After upgrading to Plasma 5.25, "sudo chmod u+s /usr/lib/kcheckpass" doesn't work because Plasma 5.25 removes kcheckpass
kscreenlocker seems to work well with PAM. If it doesn't work for you, you might need to check on the PAM side.
For example, your PAM configurations might have problems with the NSS component of systemd (systemd/systemd#20299).
KDE screen locker is not trying to run howdy as root, so changing permission could solve the issue.
sudo chmod -R 755 /usr/lib/security/howdy
Maybe it's not so secure though.
