Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
fingerprintd/packaging/fingerprint-auth.pam

40 lines
2 KiB
Text
Raw Permalink Normal View History

Give a finger a meaning beyond "it was you" The trustlet has always reported WHICH finger matched and the daemon only ever used it to answer yes. A table in /etc/fingerprintd/actions.conf now gives each finger a meaning: run a command as root, tell the user's session, or report no-match while doing one of those anyway -- which is duress, where the phone should look like it simply did not recognise the finger. Two rules shaped the design. Root does not launch applications. The daemon has no session bus, no display and no user environment, so a `session` rule carries no command at all: the daemon emits net.catcrafts.Fingerprintd1.FingerMatched(finger, uid) and an agent in the user's own session decides what that means from the user's own configuration. The only commands in the file are ones root is meant to run. Which makes the file a root shell, and the parser treats it as one. It is refused outright unless root owns it and nobody else can write it, group included. A malformed line rejects the WHOLE file rather than being skipped: applying the prefix would leave a policy nobody wrote, and the missing half could be the one that mattered. That property is tested, and the test caught it being false the first time -- rules accumulated before the bad line survived the rejection. A system command must be an absolute path, because resolving a bare name through PATH makes what root runs depend on an environment this daemon does not control. It is double-forked with a scrubbed environment so an action may outlive the daemon (a reboot) without ever stalling the worker thread that is the only thread allowed to touch the trustlet. Ordering is deliberate: the verdict override happens before the client is told, because that is the point of duress; the session signal and the root command happen after, on the same principle that keeps the harvest and the save off the unlock path. No actions.conf ships. An example goes to /usr/share/doc, because shipping a root shell nobody asked for is not a default. Not yet exercised on hardware.
2026-09-05 05:12:41 +02:00
#%PAM-1.0
# SPDX-License-Identifier: GPL-3.0-only
# SPDX-FileCopyrightText: Copyright (C) 2026 Catcrafts®
#
# The service kscreenlocker's /etc/pam.d/kde-fingerprint substacks, and which
# nothing on Alpine provides -- so on a stock pmOS image every fingerprint
# unlock fails before it reaches any daemon, with PAM unable to open the
# substack rather than anything about fingerprints. kscreenlocker ships
# kde-fingerprint (auth/account/password/session all `include fingerprint-auth`)
# and Alpine ships pam_fprintd, and the file joining them is simply absent.
#
# It lives in the vendor directory /usr/lib/pam.d, next to Alpine's own
# base-auth, so an administrator can still override it in /etc/pam.d.
#
# fingerprintd ships it because fingerprintd is what makes it mean anything:
# this package provides fprintd, so it owns the bus name pam_fprintd talks to.
# pam_fprintd asks the daemon to verify, prompting through the PAM
# conversation; sufficient, so a match ends the stack successfully and a
# failure falls through to pam_deny rather than to a password -- the caller
# (kde-fingerprint) is the one that decides whether to offer a password next.
An agent, so a finger can mean something in your session The daemon announces every matched finger on the system bus and stops there, because root has no session bus, no display and no business starting your applications. fingerprintd-agent is the other half: it runs as you, subscribes properly rather than parsing gdbus monitor output, filters by uid because the signal is visible to every local user, and maps fingers to commands from a file you own and can edit without restarting anything. It is a separate binary and a separate subpackage because it is a separate trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it is an ordinary dotfile. Demonstrated on the phone: one press of the unlock finger both unlocks it and opens plasma-camera.
2026-09-05 06:21:53 +02:00
# timeout: pam_fprintd defaults to 30 seconds and the lock screen arms
# fingerprint exactly ONCE when it appears, so on a stock setup the sensor is
# live for half a minute and then silently is not -- a press after that reaches
# nothing at all, which reads as a broken sensor rather than an expired window.
# 60 s is a compromise, not a fix: every second of it is our verify loop
# polling the trustlet at ~5 Hz, so the honest ceiling on this number is set by
# the idle-IRQ work (fp6 journal/fingerprint, "SENSOR POWER"). Raise it once an
# idle verify costs nothing.
Give a finger a meaning beyond "it was you" The trustlet has always reported WHICH finger matched and the daemon only ever used it to answer yes. A table in /etc/fingerprintd/actions.conf now gives each finger a meaning: run a command as root, tell the user's session, or report no-match while doing one of those anyway -- which is duress, where the phone should look like it simply did not recognise the finger. Two rules shaped the design. Root does not launch applications. The daemon has no session bus, no display and no user environment, so a `session` rule carries no command at all: the daemon emits net.catcrafts.Fingerprintd1.FingerMatched(finger, uid) and an agent in the user's own session decides what that means from the user's own configuration. The only commands in the file are ones root is meant to run. Which makes the file a root shell, and the parser treats it as one. It is refused outright unless root owns it and nobody else can write it, group included. A malformed line rejects the WHOLE file rather than being skipped: applying the prefix would leave a policy nobody wrote, and the missing half could be the one that mattered. That property is tested, and the test caught it being false the first time -- rules accumulated before the bad line survived the rejection. A system command must be an absolute path, because resolving a bare name through PATH makes what root runs depend on an environment this daemon does not control. It is double-forked with a scrubbed environment so an action may outlive the daemon (a reboot) without ever stalling the worker thread that is the only thread allowed to touch the trustlet. Ordering is deliberate: the verdict override happens before the client is told, because that is the point of duress; the session signal and the root command happen after, on the same principle that keeps the harvest and the save off the unlock path. No actions.conf ships. An example goes to /usr/share/doc, because shipping a root shell nobody asked for is not a default. Not yet exercised on hardware.
2026-09-05 05:12:41 +02:00
auth required pam_env.so
An agent, so a finger can mean something in your session The daemon announces every matched finger on the system bus and stops there, because root has no session bus, no display and no business starting your applications. fingerprintd-agent is the other half: it runs as you, subscribes properly rather than parsing gdbus monitor output, filters by uid because the signal is visible to every local user, and maps fingers to commands from a file you own and can edit without restarting anything. It is a separate binary and a separate subpackage because it is a separate trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it is an ordinary dotfile. Demonstrated on the phone: one press of the unlock finger both unlocks it and opens plasma-camera.
2026-09-05 06:21:53 +02:00
auth sufficient pam_fprintd.so timeout=60
Give a finger a meaning beyond "it was you" The trustlet has always reported WHICH finger matched and the daemon only ever used it to answer yes. A table in /etc/fingerprintd/actions.conf now gives each finger a meaning: run a command as root, tell the user's session, or report no-match while doing one of those anyway -- which is duress, where the phone should look like it simply did not recognise the finger. Two rules shaped the design. Root does not launch applications. The daemon has no session bus, no display and no user environment, so a `session` rule carries no command at all: the daemon emits net.catcrafts.Fingerprintd1.FingerMatched(finger, uid) and an agent in the user's own session decides what that means from the user's own configuration. The only commands in the file are ones root is meant to run. Which makes the file a root shell, and the parser treats it as one. It is refused outright unless root owns it and nobody else can write it, group included. A malformed line rejects the WHOLE file rather than being skipped: applying the prefix would leave a policy nobody wrote, and the missing half could be the one that mattered. That property is tested, and the test caught it being false the first time -- rules accumulated before the bad line survived the rejection. A system command must be an absolute path, because resolving a bare name through PATH makes what root runs depend on an environment this daemon does not control. It is double-forked with a scrubbed environment so an action may outlive the daemon (a reboot) without ever stalling the worker thread that is the only thread allowed to touch the trustlet. Ordering is deliberate: the verdict override happens before the client is told, because that is the point of duress; the session signal and the root command happen after, on the same principle that keeps the harvest and the save off the unlock path. No actions.conf ships. An example goes to /usr/share/doc, because shipping a root shell nobody asked for is not a default. Not yet exercised on hardware.
2026-09-05 05:12:41 +02:00
auth required pam_deny.so
account include base-account
# A fingerprint cannot set a password, and kde-fingerprint includes this
# service for `password` as well.
password required pam_deny.so
session include base-session
Reference in a new issue Copy permalink