[Feature] Support parallel unlocking with fingerprint and password

[Jackaed]

The only thing I've seen that supports this correctly so far is GDM, which runs 2 PAM sessions in parallel, one for fingerprint, one for password. This makes the whole "press enter to trigger the prompt" song and dance unnecessary.

I'm unsure of how this actually works in terms of implementation, but only that it is possible (since GDM can do it).

Would be very nice if Hyprlock could support it.

[PointerDilemma]

Running two pam conversations in parallel sound weird xD.

You could check out https://github.com/hyprwm/hyprlock/pull/205. There is a guy who uses pam-fprint-grosshack to make it work.

[Jackaed]

pam-fprint-grosshack is called that for a reason - PAM is strictly a serial authentication mechanism.

The correct way of doing parallel authentication is through two PAM sessions.

[PointerDilemma]

Idk if there is a correct way of doing parallel authentication xD But you might be right that having two conversations is the better solution.

You could get two pam sessions by running a script together with hyprlock that then sends SIGUSR1 to unlock hyprlock I guess.

[discapes]

presenting ~/.local/bin/mylock

#!/bin/sh
set -euo pipefail
(
until fprintd-verify -f right-ring-finger; do
    echo "Failed to verify fingerprint at $(date)" | systemd-cat
done
echo "Unlocked at $(date)" | systemd-cat
pkill -USR1 hyprlock
) &
exec hyprlock

Remember to remove the fprintd module from pam

[Jackaed]

This kinda works ish? It's pretty prone to causing just a dangling fprintd-verify, say if you authenticate with a password instead, which will make your fingerprint sensor unusable until you kill that task. I wouldn't reccomend it.

[discapes]

@Jackaed good observation, I don't really use fprintd for anything else :smile:. To fix the dangling fprint-verify, remove the exec and add these two lines:

kill $(jobs -p)
pkill fprintd-verify

[Jackaed]

Oh I just realised, this code REALLY doesn't work, since fprintd-verify still returns on a no-match, just with different output.

[discapes]

That's why there's the until loop https://linuxize.com/post/bash-until-loop/

[Jackaed]

No but that until loop still breaks if an incorrect finger is used, as fprint still returns with a non-zero exit code. You can fix it by adding | grep "verify-match" to the condition.

[discapes]

In bash, if the exit code is non-zero, it usually means a failure. fprintd-verify also works like this and returns 0 for success, and 1 for failure.

❯ fprintd-verify -f right-ring-finger
Using device /net/reactivated/Fprint/Device/0
Listing enrolled fingers:
 - #0: right-ring-finger
Verify started!
Verifying: right-ring-finger
Verify result: verify-match (done)                                              /1.1s
❯ echo $?
0                                                                               /0.0s
❯ fprintd-verify -f right-ring-finger
Using device /net/reactivated/Fprint/Device/0
Listing enrolled fingers:
 - #0: right-ring-finger
Verify started!
Verifying: right-ring-finger
Verify result: verify-no-match (done)                                           /2.0s
❯ echo $?
1

The until loop works such that it runs the command until the exit code is 0.

[discapes]

You should've tested it

[Jackaed]

My fprintd doesn't behave this way - I get an exit code of 0 on a match or on a non-match. Not sure why this is different on my machine.

I'm on nixos with nixpkgs unstable, what OS are you running? In general doing it this way is still really inconsistent and behaves weirdly when interacting with things like sleep, so for anyone else reading this thread, I wouldn't recommend doing things this way.

[discapes]

Interesting if it behaves that way. I'm using fprintd-1.94.2-8.fc39.x86_64 from Fedora. Also, I'm aware the script is a bit of a hack and I'm not forcing anyone to use it. I still don't see any major problems though, since according to the rules of bash it is impossible to unlock the computer without fprintd-verify returning 0.

I'd like to know how it "behaves weirdly" with sleep, since usually sleeping is completely transparent to processes.

[niksingh710]

For me, the current issue is that if I type my password and press enter, it waits for my fingerprint to unlock.

Here is a sway lock implementation that fixes that https://github.com/SL-RU/swaylock-fprintd

[Jackaed]

@discapes I think it's more or less working as intended now - I'm now using the script with the modifications for my distro (specifically adding the grep) and it seems to work fine with sleep.

In terms of not making it wait for fingerprint, if you're using the fprintd-verify script you can remove the fprint pam module and it should allow you to enter a password and have it work correctly, or let you use your fingerprint and have that work correctly.

I still think this should be implemented inside of hyprlock, as this still is a bit of a hack and requires a decent amount of setup, but for now this is fine.

[niksingh710]

@Jackaed can you share the method you are using or the script?

[Jackaed]

Currently using what I've modified from what @discapes sent

#!/bin/sh
set -euo pipefail
if [ -f /tmp/locked ] ; then exit ; fi
touch /tmp/locked
(
until fprintd-verify | grep "verify-match"; do
    echo "Failed to verify fingerprint at $(date)" | systemd-cat
done
echo "Unlocked at $(date)" | systemd-cat
pkill -USR1 hyprlock
) &
hyprlock
rm /tmp/locked
kill $(jobs -p)
pkill fprintd-verify

The /tmp/locked stuff is just to ensure that you don't end up with multiple instances of hyprlock going at a given time. Use this at your own risk, I'm not responsible for anything that happens as this being potentially insecure - although I'm comfortable enough with it to use it myself.

[niksingh710]

@Jackaed for me pkill -USR1 hyprlock is never getting executed i even tried it with grep verify-no-match to check if it unlocks even if the fingerprint is not verifying but no luck. only getting it unlocked by password input.

[Jackaed]

sorry this is impossible for me to debug when it's not my own system. make sure that pkill works as intended and that your fprintd-verify gives the output required.

[b4shful]

Came across this issue and wanted to ask if the situation has changed at all? I've been using pam-fprint-grosshack and it's not all that reliable (sometimes it works, sometimes I have to press enter and then wait for JUST the right amount of time (but not too early, or not too late?!?!).

[winkelnp]

I found a workaround that seems to work for me on the equivalent swaylock issue: https://github.com/swaywm/swaylock/issues/61#issuecomment-965175390

you essentially add

auth    sufficient      pam_unix.so       try_first_pass likeauth nullok
auth    sufficient      pam_fprintd.so

to the top of your /etc/pam.d/hyprlock file I'm not sure if this adds any security issues, but it works a charm for me so far… (you do however need to disable ignore-empty-input in your hyprlock.conf and entering a wrong password just fails silently)

[baykalokandemir]

I found a workaround that seems to work for me on the equivalent swaylock issue: swaywm/swaylock#61 (comment)

you essentially add

auth    sufficient      pam_unix.so       try_first_pass likeauth nullok
auth    sufficient      pam_fprintd.so

to the top of your /etc/pam.d/hyprlock file I'm not sure if this adds any security issues, but it works a charm for me so far… (you do however need to disable ignore-empty-input in your hyprlock.conf and entering a wrong password just fails silently)

This seems to work, ish? Unless i enter a wrong password in advance, i can't seem to trigger it to unlock. Works fine after wrong password though.

[winkelnp]

I found a workaround that seems to work for me on the equivalent swaylock issue: swaywm/swaylock#61 (comment) you essentially add

auth    sufficient      pam_unix.so       try_first_pass likeauth nullok
auth    sufficient      pam_fprintd.so

to the top of your /etc/pam.d/hyprlock file I'm not sure if this adds any security issues, but it works a charm for me so far… (you do however need to disable ignore-empty-input in your hyprlock.conf and entering a wrong password just fails silently)

This seems to work, ish? Unless i enter a wrong password in advance, i can't seem to trigger it to unlock. Works fine after wrong password though.

You still need to press enter (on empty input) to trigger pam

[Jackaed]

You can do that correctly strictly with PAM, which is fine - but having a parallel mechanism would be far superior if it can be implemented.

[b4shful]

@Jackaed yeah for sure - also I have a feeling that pam-fprint-grosshack may have grossed its last hack - or maybe not, but it did stop working completely on me today (some dbus error, could be a me problem, but pam_fprintd works fine). So it's definitely overdue.

[enesbala5]

I am new to the Linux space - is this really that difficult to implement to Hyprlock directly?

Why should the user have to configure something like this - which is basic UX. Half the time my fingerprint doesn't work. This is not a small "annoyance". It's actually unusable right now.

[PointerDilemma]

Fprintd provides a dbus API, which could be used by hyprlock. That would probably work a lot better than the pam module.

Besides dbus, AFAIK there are quite a few hassles implementing it.

But yeah fingerprint support on linux is bad. I think it can be blamed on PAM and windows only fp devices. The fp sensor on my laptop does not have a working fprint driver, so I will likely not dive into this.

[enesbala5]

Is there any alternative right now to Hyprlock - which can be used along Hyprland - that doesn't have this problem?

[fiskhest]

Is there any alternative right now to Hyprlock - which can be used along Hyprland - that doesn't have this problem?

If I understand the question correctly, https://github.com/SL-RU/swaylock-fprintd

[enesbala5]

Is there any alternative right now to Hyprlock - which can be used along Hyprland - that doesn't have this problem?

If I understand the question correctly, https://github.com/SL-RU/swaylock-fprintd

Thank you for the response. I am on NixOS right now - so maybe will try this later.

At this point I'm willing to remove the lock screen all together. I'd rather that than have my laptop "freeze" anytime I try unlocking it.