Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have to scan fingerprint after entering password #61

Open
erazemk opened this issue Mar 19, 2019 · 44 comments
Open

Have to scan fingerprint after entering password #61

erazemk opened this issue Mar 19, 2019 · 44 comments

Comments

@erazemk
Copy link

erazemk commented Mar 19, 2019

Swaylock version: 1.3
OS: Arch Linux
Sway version: 1.0
Laptop: Thinkpad T540p

If I lock the screen with swaylock I have to enter the password (obviously), but after entering the correct password, it will not let me in. This is when my fingerprint reader starts showing its "scanning" light. It only lets me in when I scan my fingerprint.

The scanner doesn't start until I enter something (Not necessarily my actual password - can even press Enter) and doesn't work even if entering right password (until I scan my fingerprint).

It appears that the fingerprint scanner doesn't start automatically until a key press triggers the login process.

@rsansores
Copy link

I'm not sure if this is a bug. What is happening is that PAM is launched when you press "Return" key. Your PAM must be configurated to first request fingerprint so even if you write your password PAM will ignore the input and wait for the fingerprint.

In a GDM this is not an issue because there are two steps.

Step 1: request the user to login
Step 2: request password

After step 1 PAM is called. But in the end, sway-lock is not a GDM, is just a tool to lock a wayland session.

As workaround you could:

  • Configure PAM to not request fingerprint for swaylock.

or

  • Unlock without password. Just press enter to unlock and put your finger in the fingerprint reader.

or

  • Fork sway lock to add some functionality to make the election of fingerprint or password depending on the /etc/pam.d/swaylock pam configuration.

@ghost
Copy link

ghost commented Dec 5, 2019

Fork sway lock to add some functionality to make the election of fingerprint or password depending on the /etc/pam.d/swaylock pam configuration.

I'm facing the same behavior as the one described in this issue, and I'd like to try to implement this feature.
I imagine a flag like --early-pam or something like that, that would trigger the verification right away. Would this be an interesting feature to merge on swaylock once implemented ?

@calebccff
Copy link

Fork sway lock to add some functionality to make the election of fingerprint or password depending on the /etc/pam.d/swaylock pam configuration.

I'm facing the same behavior as the one described in this issue, and I'd like to try to implement this feature.
I imagine a flag like --early-pam or something like that, that would trigger the verification right away. Would this be an interesting feature to merge on swaylock once implemented ?

Would be sweet if you're still thinking about it, an important note is that fprintd will (and should) timeout, so I'm not sure how feasible this is.

@ardevd
Copy link

ardevd commented Jan 16, 2021

Any news on this? I'm having a hard time with swaylock after adding fingerprint auth in Gnome.

@calebccff
Copy link

calebccff commented Jan 16, 2021

Any news on this? I'm having a hard time with swaylock after adding fingerprint auth in Gnome.

Not sure if you read the other comments, you don't have to enter your password... When you hit enter swaylock will attempt to authenticate with pam, in this case rather than sending your password, pam will call fprintd and wait for your fingerprint to auth.

So in summary, hit enter, scan finger, will unlock

Might be worth closing this issue as it doesn't seem realistic to change that behaviour, unless sway can detect your default authentication method which seems like security risk. Or implement a solution similar to GDM that lets you auth with both at any point.

@mnd999
Copy link

mnd999 commented Jan 17, 2021

The current behaviour is super-unintuitive so I don’t think this issue should be closed without either making it work more intuitively or (more likely) documenting it with a howto or similar.

@andrino-meli
Copy link

Maybee You are interested how to do the workaround mentioned by @rsansores.

  • Unlock without password. Just press enter to unlock and put Your finger in the fingerprint reader.

So here an elaboration:

According to https://wiki.archlinux.org/title/Fprint having these 2 lines at the very top of /etc/pam.d/swaylock

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

will still allow You to authenticate with a password as usuall. However additionally if You provide a blank, so just by pressing enter with no prior input, it will switch to finger print authentication. However make sure that You allow blank input in the swaylock configuration for this to work. Namely delete (or comment out) ignore-empty-password in ~/.config/swaylock/config if it is present.

Hope this helps someone.

@anpandey
Copy link

Fork sway lock to add some functionality to make the election of fingerprint or password depending on the /etc/pam.d/swaylock pam configuration.

I'm facing the same behavior as the one described in this issue, and I'd like to try to implement this feature.
I imagine a flag like --early-pam or something like that, that would trigger the verification right away. Would this be an interesting feature to merge on swaylock once implemented ?

Would be sweet if you're still thinking about it, an important note is that fprintd will (and should) timeout, so I'm not sure how feasible this is.

Another potential issue worth considering is when swaylock is used with swayidle's before-sleep. On my machine at least, PAM fails after a sleep when waiting for a fingerprint because the fingerprint module is powered off. You could just use after-resume, but then there's the issue of the desktop being briefly visible after waking up but before swaylock starts.

A workaround might be to have a separate command-line program that just spawns a layer-shell to cover the desktop before sleep, and spawns a swaylock process on any sort of activity (so we only start swaylock after resume).

@Moelf
Copy link

Moelf commented Apr 25, 2022

using https://frame.work with Sway on arch and I was so confused...

any update / pointer to where to implement this?

@miXwui
Copy link

miXwui commented Apr 25, 2022

@Moelf I'm using Sway on Fedora on a Framework laptop as well.

It's been about half a year without issue using @andrino-meli's comment above with @rsansores's workaround:
#61 (comment)

Note that with some applications like Swaylock, you may need to first press enter to submit a blank password, then swipe your finger.

@Moelf
Copy link

Moelf commented Apr 25, 2022

Yeah that works for me too, I guess this issue can be closed ?

@calebccff
Copy link

calebccff commented Apr 25, 2022

I've also been dealing with this workaround for quite some time. I think swaylock should have some logic to detect an active fingerprint reader and - for example - give some kind of "press enter to scan finger" message, as well as skipping the aforementioned foot-guns (ignore-empty-password).

imo the behaviour as it stands doesn't make for good UX and should be improved upon to justify actually closing this issue, if it's closed as is I would expect new similar issues to be opened as people no longer find this one.

it's been 3 years, and swaylock still doesn't support FP readers properly /shrug

@mnd999

This comment was marked as off-topic.

@emersion
Copy link
Member

it's been 3 years, and swaylock still doesn't support FP readers properly /shrug

it's been 3 years, and nobody bothered submitting a patch nor doing some research on what would be required to improve swaylock /shrug

@ldelossa
Copy link

ldelossa commented Jun 6, 2022

#61 (comment) works like a charm for this 👍

@tombh
Copy link

tombh commented Jul 22, 2022

Whilst I can unlock with my fingerprint reader, I am unclear as to what the actual method is! For instance, sometimes it'll happen instantly other times after 10 seconds. Sometimes it helps by pressing Enter once and other times twice.

I have:

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

and no .config/swaylock/config (hence I assume there is no ignore-empty-password set).

@tv42
Copy link

tv42 commented Jul 25, 2022

@tombh My guess is the fingerprint scanner is finicky and doesn't always want to recognize the finger on the first try, and there's no UI feedback about that.

@tombh
Copy link

tombh commented Jul 25, 2022

Thanks, yes that's what I thought too. But if I have dmesg tailed whilst doing say a sudo auth, I always see immediate "success" log lines.

@paulodiovani
Copy link

paulodiovani commented Aug 27, 2022

Maybee You are interested how to do the workaround mentioned by @rsansores.

  • Unlock without password. Just press enter to unlock and put Your finger in the fingerprint reader.

So here an elaboration:

According to https://wiki.archlinux.org/title/Fprint having these 2 lines at the very top of /etc/pam.d/swaylock

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

will still allow You to authenticate with a password as usuall. However additionally if You provide a blank, so just by pressing enter with no prior input, it will switch to finger print authentication. However make sure that You allow blank input in the swaylock configuration for this to work. Namely delete (or comment out) ignore-empty-password in ~/.config/swaylock/config if it is present.

Hope this helps someone.

This works fine, but there is a problem that it never tells me if I type an incorrect password, it just fails silently and password auth never works again (only fprint).

@ispanos
Copy link

ispanos commented Sep 4, 2022

According to https://wiki.archlinux.org/title/Fprint having these 2 lines at the very top of /etc/pam.d/swaylock

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

will still allow You to authenticate with a password as usuall. However additionally if You provide a blank, so just by pressing enter with no prior input, it will switch to finger print authentication. However make sure that You allow blank input in the swaylock configuration for this to work. Namely delete (or comment out) ignore-empty-password in ~/.config/swaylock/config if it is present.

Hope this helps someone.

Hello,

First of all, thanks for sharing this here. It is so useful it should be added in the sway wiki.

My input to this issue is this.

Coming back to a wm from Gnome, I should say that having to press enter before using the scanner, isn't any worse than having to open the password prompt in GDM and then use the fingerprint scanner. It's the same process actually. You press enter or space to select the user and then scan your print.

BUT! I took me longer that I am willing to admit, to understand what was happening. It was only after randomly trying things that I managed to unlock my session.

The best thing I could hope for would be, to have an option to skip pressing enter altogether and just scan the fingerprint. But if it isn't straight forward, and no-one is willing to do it, I have some other suggestions.

  • Add an (option for) indication that 2FA or a fingerprint scanner is enabled
  • Add the above solution to the man page and --help (if not in more places)
  • Add the configuration to /etc/pam.d/swaylock, by default, as a comment

Fingerprint scanners are getting more common. I bet that soon they are going to be added on mainstream keyboards. I understand that the goal is not to make swaylock more complicated, but it has to be a tiny bit better in the UX department. At the very least make the issue known to the users, without bringing them here.

Thanks for making my wm more secure.

@SL-RU
Copy link

SL-RU commented Jan 24, 2023

I've started to implement fingerprint functionality into swaylock. It is based on fprintd DBus service. It will always wait for finger and will not require to press any button before scanning. It already works but I need to use normal event loop and test it.

https://github.com/SL-RU/swaylock-fprintd

@SL-RU
Copy link

SL-RU commented Jan 28, 2023

Fingerprint scanning works perfectly now. BUT only if system doesn't suspends. After suspend fprintd cannot correctly wake up the device. This issue is already opened and even MR exists: https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/270

Now I'll be watching it's status and when it will be ready I'll finish that task

@SL-RU
Copy link

SL-RU commented Jan 29, 2023

Who are not afraid can compile and test it from #283

@SL-RU
Copy link

SL-RU commented Jan 30, 2023

Package with fingerprint support on AUR: https://aur.archlinux.org/packages/swaylock-fprintd-git

@J053Fabi0
Copy link

@SL-RU, what is your /etc/pam.d/swaylock configuration?

@SL-RU
Copy link

SL-RU commented Jan 30, 2023

@SL-RU, what is your /etc/pam.d/swaylock configuration?

The default one

❯ cat /etc/pam.d/swaylock
#
# PAM configuration file for the swaylock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#

auth include system-auth

@J053Fabi0
Copy link

Then what configuration is needed to prompt for the fingerprint?

@SL-RU
Copy link

SL-RU commented Jan 30, 2023

Then what configuration is needed to prompt for the fingerprint?

Ooh, you need to add argument -p or alias --fingerprint. You can check --help. For example

swaylock -p -c 111111

@notmentaloutlaw
Copy link

notmentaloutlaw commented Feb 9, 2023

For /etc/pam.d/swaylock I have this and it works fine.

# PAM configuration file for the swaylock screen locker. By default, it includes
# the 'login' configuration file (see /etc/pam.d/login)
#

auth            required        pam_u2f.so         authfile=/etc/u2f_mappings
auth		include		system-login
account		include		system-login
password	include		system-login
session		include		system-login

This is for a yubikey but I am sure you can modify it to fit your requirements. Now how it works for me is I first do a password then I touch the yubikey then it opens.

@lack
Copy link

lack commented Feb 10, 2023

@SL-RU Your fork works perfectly! I'd love to see a bit more visual feedback (like the circle could pop up and say "scanning" or something when I place my finger on the reader), but your fork is awesome. No delays whether I use the fingerprint scanner or password, and no PAM changes needed.

@SL-RU
Copy link

SL-RU commented Feb 10, 2023

Thank you for the review @lack ! I'm glad that it works for you! 😄

Yeah, I want to add more textual feedback in next commits too.

@WhyNotHugo
Copy link
Contributor

Does pam itself timeout? swaylock could, potentially:

  • Call pam_start when started.
  • Call pam_authenticate.
  • At this point, tapping a fingerprint reader would unlock the session if that is sufficient.
  • If a password is required, pam will call the pam_conv handler. This handler must block.
  • Once the user provides a password, the pam_conv handler should return.
  • If pam_authenticate returns error, go back to the first step immediately.

This should work well for fingerprint-only, fingerprint+password and password-only, assuming pam does not time out sessions. The implementation won't be the nicest though, it requires a child that is blocked by the parent until the password is provided.

@kennylevinsen
Copy link
Member

PAM does not timeout, but nothing stops a module from having its own timeout (like a fingerprint reader having a timeout for how long it will hang waiting for fingerprint). PAM also has no way to abort if one is hanging in an authentication call - control is only handed back during the conversation function.

If a fingerprint-reading module is put before pam_unix, it means that PAM will not ask for a password until the fingerprint module fails or times out. If you want to log in with password, you must first fail fingerprint scanning, and you have to repeat that for every password attempt if you type your password wrong.

PAM is not suitable for having multiple equally valid means of authentication j(without hacks like spawning multiple processes with independent PAM stacks, and taking the first success).

@WhyNotHugo
Copy link
Contributor

Right, fingerprint itself will time out. But I guess that my above suggestion can be put in a while (true) loop, so that whenever one approaches a locked device, a pam session is in progress and awaiting fingerprint input... but that has lots of other issues. Like all the successive failed attempts.

Any idea how other DEs work around this issue (e.g.: so as to allow approaching the device and tapping the fingerprint reader to unlock).

@rrueger
Copy link

rrueger commented Oct 6, 2023

If your fingerprint reader is also a physical, pressable button (like on newer Dell XPS/Inspiron series), you can remap the button to press enter, and so only one finger press is required (because the button simulates pressing enter for you).

Here is an example configuration.

You must have some sort of keyboard input simulation tool installed for this. This example uses ydotool.

To configure ydotool, you must find the keycode for enter on your keyboard using libinput record or looking in /usr/include/linux/input-event-codes.h. In my case, the enter key has keycode 28, so executing

ydotool key 28:1 28:0

will simulate pressing the enter key once. Now we add to our sway config

bindsym --no-repeat --locked XF86PowerOff exec ydotool key 28:1 28:0

Note(!) --locked is important, otherwise swaylock will ignore this bindsym when locked. If you still want the power key to do whatever you configured it to be before when the screen is not locket, e.g. it executes ~/bin/powermenu, then you can add

bindsym --no-repeat --locked XF86PowerOff exec bash -c "if (($(pgrep -cx swaylock) > 0)); then ydotool key 28:1 28:0; else ~/bin/powermenu; fi"

Now, you still get usual functionality from the powerkey (e.g. opening a powermenu) when the system is not locked, and when the system is locked, it will simulate pressing enter, so unlocking with the fingerprint requires only one press.

PS: If your fingerprint button is the power key On my (most?) machines the fingerprint reader is on the power key. Usually the default action of the power key is to immediately turn off the machine. We don't want this, so we must inhibit the power key. You can do this in systemd-logind by adding a dropin file /etc/systemd/logind.conf.d/00-power-key.conf with content

[Login]

HandleHibernateKey=ignore
HandlePowerKey=ignore
HandleRebootKey=ignore
HandleSuspendKey=ignore

@rrueger
Copy link

rrueger commented Oct 6, 2023

SL-RU's comment from above

Fingerprint scanning works perfectly now. BUT only if system doesn't suspends. After suspend fprintd cannot correctly wake up the device. This issue is already opened and even MR exists: https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/270

Now I'll be watching it's status and when it will be ready I'll finish that task

I also had a suspend/resume issue. I am not sure if it is the same as yours.

This was the issue I faced, and includes a solution.

The issue is a polkit permissions problem: for some reason fprintd tries to "enroll" a fingerprint when verifying

failed to claim device: GDBus.Error:net.reactivated.Fprint.Error.PermissionDenied: Not Authorized: net.reactivated.fprint.device.enroll

The fix is to add a polkit rule that allows all users to enroll fingerprints

polkit.addRule(function (action, subject) {
  if (action.id == "net.reactivated.fprint.device.verify") {
    return polkit.Result.YES
  }

I don't know what the security implications are. To me, it doesn't seem like a huge problem if users can enroll fingerprints themselves (without root permissions). I suppose some system administrators don't want some users to be able to log in with fingerprints? On personal machines, I don't see this being an issue.

@rrueger
Copy link

rrueger commented Oct 6, 2023

@emersion I appreciate that you do not want to merge SL-RU's fork for maintenance reasons. Would it be possible to merge the textual feedback logic? I don't understand SL-RU's entire implentation, but the feedback part (first half of the verify_result function) looks like it is independent of any dbus work? (However, of course I am happy to stand corrected)

@emersion
Copy link
Member

emersion commented Oct 6, 2023

I'd rather not add the complexity of a D-Bus API to swaylock.

@ispanos
Copy link

ispanos commented Oct 6, 2023

@rrueger Helpful comment. Especially the bindsym --no-repeat --locked is something that I hadn't checked out.

My biggest issue was that my fingerprint scanner sometimes disappeared (not related to the suspend issue above). When that happened, swaylock gave me absolutely no indication that the fingerprint scanner was not working and it always took me some time to realize and enter my password. GDM, which was what I used to "solve" this issue, removes the "use your fingerprint" message when this happens.

I own a Thinkpad p14s gen2i with the latest firmware updates. I'm not asking for support, unless you have heard about this and remember the solution. I'm only mentioning to support my original comment:

Add an (option for) indication that 2FA or a fingerprint scanner is enabled

@celia-vytrac
Copy link

celia-vytrac commented Mar 3, 2024

On gentoo with @SL-RU 's fork, the default configuration of sys-auth/fprintd-1.94.2 installs this file: /usr/share/polkit-1/actions/net.reactivated.fprint.device.policy which blocks all users except root from using net.reactivated.fprint.device.verify and gives this error

2024-03-03 10:14:27 - [fingerprint/fingerprint.c:79] Fingerprint: using device /net/reactivated/Fprint/Device/0
2024-03-03 10:14:27 - [fingerprint/fingerprint.c:93] failed to claim the device: GDBus.Error:net.reactivated.Fprint.Error.PermissionDenied: Not Authorized: net.reactivated.fprint.device.enroll(36)

In order for swaylock-fprintd to verify correctly I needed to add a polkit rule in /etc/polkit-1/rules.d

50-net.reactivated.fprint.device.verify.rules

polkit.addRule(function (action, subject) {
  if (action.id == "net.reactivated.fprint.device.verify") {
    return subject.isInGroup("wheel") ? polkit.Result.YES : polkit.Result.NO
  }
})

I am also using the default swaylock pam

auth    include         system-auth

I based the polkit rule on this arch wiki https://wiki.archlinux.org/title/fprint#Restrict_enrolling

@Chaitran77
Copy link

Chaitran77 commented Jun 23, 2024

I'm getting this error both when trying to install from pacman or compile from source on Arch:

Dependency gio-2.0 found: YES 2.80.3 (cached)
Program /usr/bin/gdbus-codegen found: NO

fingerprint/meson.build:12:29: ERROR: Dependency 'gio-2.0' tool variable 'gdbus_codegen' contains erroneous value: '/usr/bin/gdbus-codegen

This is a distributor issue -- please report it to your gio-2.0 provider.

I'm not sure if it's an upstream issue (guess that would mean this repo) or not, but I have tried to install/reinstall glib, glib2 (which hold gio-2.0) to try and resolve the issue to no avail.

Would like some help with this if at all possible. Thank you.

@kennylevinsen
Copy link
Member

Please discuss forks on the issue tracker of said fork, rather than here.

@bjornpijnacker
Copy link

bjornpijnacker commented Sep 2, 2024

@paulodiovani

This works fine, but there is a problem that it never tells me if I type an incorrect password, it just fails silently and password auth never works again (only fprint).

Were you able to find a solution for this? Currently having the same issue with the suggested config options.

Edit: The issue is actually a bit different than described. If password auth fails (which happens silently) and THEN fprint auth also fails, password auth can be retried.

@paulodiovani
Copy link

Were you able to find a solution for this? Currently having the same issue with the suggested config options.

Sorry, but after some tries I went back to typed password, only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests