If the directory referred to by ReadWritePaths= does not exist, the
service fails to start:
systemd[1]: Starting Fingerprint Authentication Daemon...
systemd[9736]: fprintd.service: Failed to set up mount namespacing: No such file or directory
systemd[9736]: fprintd.service: Failed at step NAMESPACE spawning /usr/lib/fprintd/fprintd: No such file or directory
systemd[1]: fprintd.service: Main process exited, code=exited, status=226/NAMESPACE
systemd[1]: fprintd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Fingerprint Authentication Daemon.
This may happen when booting with an empty /var filesystem.
For a system service, "StateDirectory=fprint" causes /var/lib/fprint and
any parent directories to be created if missing (with mode 0755 by
default, owned by the user and group of the service, which in this case
is root). In combination with ProtectSystem=strict, this state
directory will be mounted read-write. StateDirectory was introduced in
systemd 235, so require at least this version.
The /var/lib prefix is hardcoded in systemd. (Since systemd 240, the
full path(s) to StateDirectory are provided as $STATE_DIRECTORY, but
since it is always /var/lib, we continue to just hardcode that path.)
On non-systemd systems, since fprintd runs as root with no confinement,
it can create its state directory as needed (with g_mkdir_with_parents()
in file_storage_print_data_save()).
--localstatedir (and --prefix) will now be ignored in favour of this
hardcoded path. This is in preparation for a change to use systemd's
StateDirectory feature.
Otherwise you could get into a state where the daemon could not start
because the directory listed as a ReadWritePaths in the .service file is
missing.
Spotted by Will Thompson.
See: !5
The gettext in fprintd would be getting confused by a new file in
libfprint that looks like it should have been translated. Ignore this
file in our build.
Fix a possible crash when an fprintd client disappears. If the client
requested for the device to be released, then, without waiting for the
reply of that release, disappeared from the bus, we would try to close
it a second time, accessing a function pointer that didn't exist
anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1515720
If not all the functions in the header are used, we'd get warnings about
them being unused. Mark all the functions as unused, so we can avoid
warnings.
Before claiming the device and therefore potentially activating
the actual hardware, make a call to see if the user has any
prints registered at all.
https://bugs.freedesktop.org/show_bug.cgi?id=99811
For some operations, i.e. listing the enrolled prints, the device
does not need to be claimed. Therefore the claiming can be delayed
until we actually start the verification process, allowing us to
query the fingerprint system if the user has any prints enrolled.
https://bugs.freedesktop.org/show_bug.cgi?id=99811
Give read-write access to USB devices in /dev, and the location of the
fingerprints, access to Unix sockets for D-Bus and
close everything else down.
See systemd.exec(5) for details about the options.
