Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
fingerprintd/packaging/actions.conf.example

52 lines
2.2 KiB
Text
Raw Permalink Normal View History

text change
2026-09-08 16:50:25 +02:00
# fingerprintd per-finger actions.
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
#
# Install as /etc/fingerprintd/actions.conf. With no such file, a finger does
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# exactly what it always did: it unlocks.
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
#
text change
2026-09-08 16:50:25 +02:00
# This file is for running root scripts on finger actions.
# For scripts that run in your session, you can use this D-Bus:
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
#
# net.catcrafts.Fingerprintd1.FingerMatched(finger, uid)
# on /net/reactivated/Fprint/Device/0
#
# This file is for the two things that do need the daemon.
#
# THIS FILE IS A ROOT SHELL. Every command here is run by root when that
# finger touches the sensor, so anything able to write it owns the machine at
# the next press. fingerprintd refuses the whole file — not just the offending
# line — unless root owns it and no one else can write it:
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
#
# sudo install -Dm644 -o root -g root actions.conf.example \
# /etc/fingerprintd/actions.conf
#
# It is read once, at startup. Editing it means restarting the unit, which is
# also when you get to see the parse errors.
#
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# Format:
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
#
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# <finger> [no-unlock] [absolute command...]
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
#
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# finger an fprintd finger name: left-thumb, left-index-finger,
# left-middle-finger, left-ring-finger, left-little-finger, and
# the right-* equivalents.
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
#
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# no-unlock this finger never unlocks. The client is told it did not match,
# whatever really happened.
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
#
text change
2026-09-08 16:50:25 +02:00
# command an absolute path, passed to /bin/sh -c with a fixed environment
# plus FINGERPRINTD_FINGER.
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
#
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# --- A finger that also does something, as root -----------------------------
#right-ring-finger /usr/local/bin/toggle-something
#
text change
2026-09-08 16:50:25 +02:00
# --- A duress finger: rejected, and the script runs anyway ------------------
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
#
text change
2026-09-08 16:50:25 +02:00
# Know what this is not: It is a panic button, not deniability. The
# rejection it fabricates is far faster than a real one. A finger the sensor
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# genuinely does not know takes about three seconds to be refused, this takes
text change
2026-09-08 16:50:25 +02:00
# milliseconds. The daemon's journal records that the finger really matched,
Drop two fields nobody needed: session was a no-op, and no-unlock is the finger Jorijn caught both. `session` declared nothing. The FingerMatched signal is emitted for every matched finger unconditionally -- it never consulted the config -- so a `session` line was a rule the format invited you to write that did exactly nothing. Announcing every finger is the right default anyway: a session agent should not need a root-owned file to declare its interest in a signal it is free to ignore. The column is gone. Which leaves the config for the two things that really do need the daemon, and with `session` gone the verdict column had no partner left to vary against. It read as a property of the finger while being a property of the attempt, so it is now written as what it is: <finger> [no-unlock] [absolute command...] no-unlock says the finger never unlocks; a command is what root runs. At least one is required, because a finger listed alone says nothing the signal does not already say -- and that is a parse error rather than a silently useless line. The example config now also states plainly what no-unlock is not. It is a panic button, not deniability: the rejection it fabricates comes back in milliseconds where a real one takes about three seconds, the journal records that the finger actually matched, the file names the finger in plain text, and the finger still shows as enrolled. Both of those weaknesses are real and neither is fixed here.
2026-09-05 05:23:40 +02:00
# this file names it in plain text, and the finger still shows as enrolled in
# fprintd-list. It reliably runs your script. It does not reliably hide that
# it did.
#
#left-little-finger no-unlock /etc/fingerprintd/panic.sh
Reference in a new issue Copy permalink