Disabling fprintd.service prevents boot

[ebsf]

Disabling fprintd.service prevents boot.

System: Ubuntu Desktop 22.04

Behavior: Rebooting immediately after disabling and masking fprintd.service, fails.

A series of [DEPEND] messages scroll past in tty1 early in the boot process, too quickly to read but that appear to be mount units failing for want of a dependency. Consistently, the last message to appear in tty1 is:

[ OK ] Reached Target Printer Support

Expected behavior: No disruption in boot process from the deletion of an irrelevant service for which no hardware exists.

Unfortunately, no further information is available because the machine resists booting.
- While booted to a separate partition, I deleted the symlink in /etc/systemd/system to /dev/null, but boot failed thereafter in the same way.
- I chrooted into the partition to attempt to re-enable the unit but the command failed by reason of being in a chroot environment.
- The partition's syslog has no entries containing DEPEND, probably because they occurred before rsyslog could receive input from the kernel ring buffer.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Could you provide some details on why you disabled the service and how? And yes it's not unexpected that manually disabling system jobs might lead to issues

[ebsf (eb-9)]

I first disabled it by including fprintd in a list of packages to purge, in an installation script. There, the service wasn't expressly disabled; the package was simply purged (apt purge fprintd).

That machine then suffered similar boot hangs, so I installed a new system and debugged the script by stepwise disabling units associated with each of the packages designated for purge in the script and rebooting (rather than removing or purging, which I planned to test later if disabling the units didn't identify the culprit). So,

# systemctl stop {foo.service | foo.socket | foo.path }
# systemctl disable {foo.service | foo.socket | foo.path }
# systemctl mask {foo.service | foo.socket | foo.path }
# reboot

The reason for removing the component is that it is irrelevant and unnecessary. The machine is a workstation and file server, not a laptop, and lacks the hardware for biometric authentication. It's a lovely addition to the suite but should never have been installed in the first place without either validating that suitable hardware exists, an installer opt-in, and probably both.

It also is profound a security risk. It provides a back door for authentication that can't obviously be monitored, blocked, or disabled. I understand that it may not have been developed to pose such a threat, and that toggling a few settings here or there may turn out to be all that is necessary to prevent this. Nevertheless, this is entirely unknowable. All that one can do is remove it when inappropriate. There isn't enough time in the day to deal with it otherwise.

So, having nevertheless been installed, it should hardly be a surprise that it would be removed immediately upon discovery in similar cases of inappropriate installation. Such removal should be anticipated with suitable requirement dependencies in other units that reflect this contingency, or otherwise.

Simply, biometric authentication is one of many authentication alternatives. Removing it is conceptually no different than disabling password authentication in ssh. Crashing ssh, or an entire system, after rooting out password authentication would be idiotic.

It may be that the package's architecture is fundamentally flawed by inserting itself into the dependency structure as it has. That may be humiliating but at least now you know.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.