RFC: Unlock using fingerprint scanner

[hojjatabdollahi]

I'm opening this PR to talk about this missing feature:

This PR adds the ability to unlock COSMIC with either the fingerprint scanner or a password.

NOTE: This does not allow logging into the system using fingerprint scanner, it only allows for unlocking an already logged in session, not the login screen!

GDM has a similar option, they have 2 pam files: gdm-password, and gdm-fingerprint. If you enable fingerprint support, it starts two workers simultaneously and whoever wins, it cancels the other one and allows the user to login or unlock.

I tried to implement a similar solution here, however, the login is handled by greetd which does not support racing two separate pam processes at the same time. Also we need the password to open gnome-keyring, so login stays password only. This only applies to unlock screen. I did not rename the default pam file, so there shouldn't be any issues since this installs a separate pam file for fp.

I added a config for cosmic-greeter to enable fingerprint support.

The lock screen would start two processes (not threads but separate processes) one waiting on password and another is waiting on fingerprint scanner. The fp one is gated on the cosmic-greeter config being enabled, and the fingerprint scanner hardware being available, and the current user having enrolled a fingerprint. Which ever process succeeds we unlock the screen, and the other process is killed so that we cancel the pam process (this is how GDM does it and is a lot stronger than if we were using threads, also more resilient to errors).

Things to consider:
1- This only applies to unlock screen, I actually prefer to login using password and unlock using fp because I do lock my screen a lot and typing my password is a PITA, but I'd prefer to login using password since I have to enter my password anyways because of gnome-keyring. It is technically not possible to unlock gnome-keyring using your fingerprint scanner, maybe if we support secure boot and TPM and... But for now logging in using fingerprint scanner is less important than unlocking an already logged in session if you ask me.
2- Most people using COSMIC, who also have a device with a fingerprint scanner have already added auth [success=2 default=ignore] pam_fprintd.so max-tries=1 timeout=10 to their /etc/pam.d/common-auth which would interfere with this. Adding that line to common-auth allows for a sequential auth everywhere, it asks for your fingerprint and when it fails or times out it asks for your password. But in the unlock screen both workers would try to get the fingerprint scanner device! I think when a UI is added to cosmic-settings to enable this feature, the user can be warned if they already have that manual change in their pam files.
3- There is no UI to enroll fingerprints or enable this feature in greeter yet. It's scheduled for Epoch 3.
4- If we want to also login using fingerprint scanner, we have to move away from greetd and implement everything in cosmic-greeter like gdm does.

Security-wise I don't see any issues, since login path is untouched. And the lock screen is running as the user, so no privileged surface to attack. Also unlock re-execs itself via /proc/self/exe which is mapped to memory so it not vulnerable to PATH poisoning, no name resolution.

---

• I have disclosed use of any AI generated code in my commit messages.
  • If you are using an LLM, and do not fully understand the changes it is making to the code base, do not create a PR.
  • In our experience, AI generated code often results in overly complex code that lacks enough context for a proper fix or feature inclusion. This results in considerably longer code reviews. Due to this, AI authored or partially authored PRs may be closed without comment.
• I understand these changes in full and will be able to respond to review comments.
• My change is accurately described in the commit message.
• My contribution is tested and working as described.
• I have read the Developer Certificate of Origin and certify my contribution under its conditions.

[jackpot51]

It makes sense to me, but I don't have a device to test with