auth: Support parallel fingerprint auth

[moggiesir]

I chose to use Fprint's dbus interface directly rather than going through pam (which uses Fprint's dbus interface) due to poor handling of system sleep somewhere between fprintd and pam. When preparing for sleep, fprintd puts the device to sleep, which causes VerifyStatus to emit with verify-unknown-error, which normally should be responded to by calling both Device.StopVerify and Device.Release (and this is what pam does). Unfortunately, if you try to release the device when the system is preparing for sleep, you'll get an error that the device is busy and then you can't can't claim or release the device for 30 seconds.

pam also has a max timeout for pam_fprintd.so of 99 seconds, and so if we used pam, we'd have to deal with the timeouts and keep restarting the auth conversation.

gdm/gnome-session lock seems to get around these issues by having a shutter on top of the lock screen that you have to interact with first that gives gnome-session a trigger to start fingerprint auth.

Fixes #258

[Kochanac]

Hello, tested this feature, here is what I think:

• when trying to use the wrong finger 3 times, hyprlock exits and unlocks the session (logs (hyprlock -v) and my config hyprlock.conf.txt, compiled from a2ef6a9)

• probably this is my config problem, but anyway: I don't see any error messages in the input field when getting verify-no-match error

• from a UX standpoint I would suggest that as an option you could add some message when starting to verify using fprint, so a user could see that the system is working correctly

[moggiesir]

Hello, tested this feature, here is what I think:

• when trying to use the wrong finger 3 times, hyprlock exits and unlocks the session (logs (hyprlock -v) and my config hyprlock.conf.txt, compiled from a2ef6a9)

This is now fixed, it was a bad state during some refactoring.

• probably this is my config problem, but anyway: I don't see any error messages in the input field when getting verify-no-match error

I didn't want to mess with the input-field so as to not introduce edge cases with the password input/error handling, so you can use $FPRINTMESSAGE in a label.

• from a UX standpoint I would suggest that as an option you could add some message when starting to verify using fprint, so a user could see that the system is working correctly

I added an option general:fingerprint_ready_message that $FPRINTMESSAGE will display when ready for fingerprint input.

[Kochanac]

Indeed the bug is fixed, thanks!

About fingerprint_ready_message, I meant another thing, sorry for the unclear explanation. I've meant that when you touch the scanner, the system should immediately display some message like "scanning..." to indicate that scan is started. I think it would be useful for improving responsiveness as sometimes the scan can be longer than 500ms

But it looks like fprint does not expose such interface, so it is probably impractical to do. fingerprint_ready_message is also useful, so I would leave it as is

[PaideiaDilemma]

I didn't want to mess with the input-field so as to not introduce edge cases with the password input/error handling, so you can use $FPRINTMESSAGE in a label.

In my opinion it would make sens to be able to have the fp feedback in the input-field, if it is empty. But for that we might want to add an abstraction so that we don't have to add logic for an additional auth module in the input-field. That could be done later.

[moggiesir]

About fingerprint_ready_message, I meant another thing, sorry for the unclear explanation. I've meant that when you touch the scanner, the system should immediately display some message like "scanning..." to indicate that scan is started. I think it would be useful for improving responsiveness as sometimes the scan can be longer than 500ms

But it looks like fprint does not expose such interface, so it is probably impractical to do. fingerprint_ready_message is also useful, so I would leave it as is

There's a property on the device for whether the finger is present, so I changed to use the PropertiesChanged signal to listen for finger presence and display a message at that time (general:fingerprint_present_message). On my device, it's pretty snappy to read my fingerprint, so I don't like the extra messages.

[PaideiaDilemma]

The rest looks pretty good.
Thanks for working on this! Sadly I cannot properly test it, because my fp reader has no fprintd driver ;(

[noxxious]

The PR needs changes to flake.nix to add extra buildInputs: sdbus-cpp and systemdLibs.

[matejdro]

I have did a quick check of this using fingerprint sensor in the ThinkPad T14s (AMD) Gen 3 and everything seem to be working well. Thanks

[PaideiaDilemma]

@vaxerski I think this looks good

[vaxerski]

minor nitpicks, rest is alr, needs a wiki mr

[moggiesir]

Opened hyprwm/hyprland-wiki#816 for the wiki

[b4shful]

Non-code related comment (apologies), but just so I understand, does this remove the need for pam_fprintd?

Many users are using various workarounds (see #258), so they will have /etc/pam.d/hyprlock files something like:

(Collapsed for readability, click headings to expand)

pam_fprintd (installed with fprintd)

/etc/pam.d/hyprlock

# PAM configuration file for hyprlock
# the 'login' configuration file (see /etc/pam.d/login)
auth	sufficient	pam_unix.so	try_first_pass likeauth nullok
auth	sufficient	pam_fprintd.so
auth	include 	login

pam-fprint-grosshack

(Source)

/etc/pam.d/hyprlock

# PAM configuration file for hyprlock
# the 'login' configuration file (see /etc/pam.d/login)
auth	sufficient	pam_fprintd_grosshack.so
auth	sufficient	pam_unix.so try_first_pass nullok
auth	include 	login

With this new parallel auth support, can we go back to using the default pam file?

hyprlock default pam file

/etc/pam.d/hyprlock

# PAM configuration file for hyprlock
# the 'login' configuration file (see /etc/pam.d/login)

auth        include     login

Once the PR is merged I will write some comments on #258 advising people on how to revert some of the workarounds so they can switch to using the built-in parallel auth functionality. Although, with some of the cursed methods people came up with (bash scripts, temp files, other abominations) I probably won't go that deep haha

[moggiesir]

Yes, with the new parallel auth support, users should go back to the default pam file.

[vaxerski]

apart from that lgtm

[PaideiaDilemma]

@vaxerski

Quite a few fixes since last release. I think a hyprlock release is due.
Wanna do that before or after this?

[vaxerski]

I need @fufexan to fix nix ci and then we can release

[vaxerski]

man I love fufexan