Reverted from Fprint#Login configuration:

!!! WARNING: the above configuration is likely horribly broken (when both authentication methods fail, it allows to login - can be easily tested, by using empty/wrong password), but I do not use fingerprint so I am unable to test it. Most likely this line is also needed:

auth requisite pam_deny.so

The reason: "sufficient" means "try it, but if it fails, move on to next rule and do not fail authentication" so if all sufficient methods fail, it simply decides that everything is fine... The deny rule at the end of all sufficient auth rules, ensures that when they all fail, the authentication process will fail as well.

—This unsigned comment is by Sado1 (talk) 2023-07-12T14:12:52. Please sign your posts with ~~~~!

We need other/alternative udev rule. Like this:

/etc/udev/rules.d/01-fingerprint.rules

ACTION=="add", RUN+="/bin/sh -c 'echo 1 >> /sys/bus/usb/devices/1-4/power/persist'"

This one is working for me, but user will need to determine its own fingerprint usb path, e.g. with

tail /sys/bus/usb/devices/*/idProduct

Veuxit (talk) 06:17, 29 November 2025 (UTC)

I think it's possible to make it more official or user friendly.

To determine the correct device id for /sys/bus we need to first find our fingerprint reader using lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver

Bus 001 Device 003: ID 13d3:5415 IMC Networks Integrated Camera

Bus 001 Device 005: ID 8087:0026 Intel Corp. AX201 Bluetooth

Bus 001 Device 029: ID 06cb:00bd Synaptics, Inc. Prometheus MIS Touch Fingerprint Reader

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 002 Device 002: ID 0781:5583 SanDisk Corp. Ultra Fit

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

The relevant line we want is:

Bus 001 Device 029: ID 06cb: Synaptics, Inc. Prometheus MIS Touch Fingerprint Reader

This line contains the product ID that we'll use in the next step, the whole ID consists of a <vendorId>:<productId>, in my case 06cb:00bd, we only want the second part after the semicolon (00bd).

Now we'll use this value in the following command:

grep -l "^00bd$" /sys/bus/usb/devices/*/idProduct | awk -F '/' '{print $(NF-1)}'

The output should look something like: 1-4, 1-9, etc.

We'll use this value for the following line in

/etc/udev/rules.d/01-fingerprint.rules

ACTION=="add", RUN+="/bin/sh -c 'echo 1 >> /sys/bus/usb/devices/<value>/power/persist'"

In my case it looks like this:

/etc/udev/rules.d/01-fingerprint.rules

ACTION=="add", RUN+="/bin/sh -c 'echo 1 >> /sys/bus/usb/devices/1-9/power/persist'"

Yaron (talk) 06:54, 30 November 2025 (UTC)

Yeah looks good, but I would also highlight <value> and 00bd.

<value>

in /etc/udev/rules.d/01-fingerprint.rules and

grep -l "^00bd$" /sys/bus/usb/devices/*/idProduct 

in grep command and

Bus 001 Device 029: ID 06cb: Synaptics, Inc. Prometheus MIS Touch Fingerprint Reader

in lsusb Veuxit (talk) 07:27, 30 November 2025 (UTC)

I modified most of it, the only problem is the <value> because it's inside a <nowiki> tag. Yaron (talk) 08:15, 1 December 2025 (UTC)

A previous version of this page included the following mitigation:

# Disallow fingerprint in sudo/su without tty

auth [success=1 default=ignore] pam_succeed_if.so service in sudo:su:su-l tty in :unknown

However, after testing, this doesn't seem to prevent fingerprint hijacking (at least on my machine/setup). As a result, I've removed it, but let me know if you can't replicate it. StatsLime (talk) 04:24, 29 December 2025 (UTC)

OTOH, this does seem to work, since it forces the user to press "enter" to use their fingerprint. This can be broken if there's some way to pipe input into the password prompt (an incorrect guess will immediately enable the fingerprint sensor).

auth sufficient pam_unix.so try_first_pass likeauth nullok

auth sufficient pam_fprintd.so

Not sure if something similar could be used for a "pin-and-print" system where you need to provide both a fingerprint and a short pin (just 4-6 characters) as a proof-of-attention. StatsLime (talk) 05:22, 29 December 2025 (UTC)

OK, sudo -S means this setting is still a security vulnerability then. StatsLime (talk) 19:05, 29 December 2025 (UTC)

There are several ways to solve it properly, the problem is that although PAM is a central module it doesn't really care about your awareness, it's just working as configured.

For better protection there should be a way to look at authentication from a more holistic way, from OS/distro/desktop environment perspective, meaning that some other entity should be aware of this attempt and assess the risk while taking all the different factors into account.

Configuring the same thing in mac works differently, there's a persistent dialog that doesn't accept the fingerprint unless focused and it works for sudo as well. Yaron (talk) 13:38, 30 December 2025 (UTC)

> There are several ways to solve it properly

Could you explain or add one to the page? I'd love to see this! StatsLime (talk) 03:53, 28 January 2026 (UTC)

Well, after talking to the the fprintd, PAM and sudo I realised that the best solution would be a centralized solution that knows whether there's UI and the authentication window must be focused for fingerprint to work, it works like that in macOS and apparently the default Ubuntu (and GNOME in general), I was having issues with KDE and I think other DEs might suffer from that vulnerability as well. Yaron (talk) 11:47, 29 January 2026 (UTC)

The information about enrollig not being restricted by default seems to be wrong/outdated. On a fresh install after installing fprint, starting fprint-enrollment as a user triggers an authentication dialogue. Fprintd version 1.94.5-1, no PpolicyKit changes made. Could anyone confirm this is indeed changed now? I assume it could be a change made in a recent fprintd version. --Naguz (talk) 14:58, 31 January 2026 (UTC)