sudo/PAM authentication always falls back to password — PipeWire refuses to start under root (ConditionUser=!root), camera capture silently fails

[Barnaby-Clifton]

Here's a full write-up, ready to paste into a new GitHub issue on TickLabVN/biopass:

---

Title: sudo/PAM authentication always falls back to password — PipeWire refuses to start under root (ConditionUser=!root), camera capture silently fails

Body:

Summary

When using libbiopass_pam.so for sudo authentication (via a custom authselect profile on Fedora), face authentication never succeeds and always silently falls through to the password prompt — despite a correctly enrolled face and a working GUI-based test. The biopass-helper process does spawn and the IR strobe fires, but no successful capture ever occurs.

Root cause

sudo runs PAM (and therefore libbiopass_pam.so → biopass-helper) as root. PipeWire's systemd user units have a hard condition preventing them from running as root:

Jul 13 21:26:20 Flip13 systemd[40087]: pipewire-pulse.socket - PipeWire PulseAudio skipped, unmet condition check ConditionUser=!root
Jul 13 21:26:20 Flip13 systemd[40087]: pipewire.socket - PipeWire Multimedia System Sockets skipped, unmet condition check ConditionUser=!root

Because biopass-helper relies on GstPipeWireSrc for camera capture (per issue #49's investigation), and PipeWire never starts a session for root, the capture pipeline has no source to read from. The helper still spawns, the camera briefly activates (IR strobe fires), but no usable frame is ever captured, so recognition can never succeed — and no debug data is written, since the pipeline dies before reaching that stage.

Steps to reproduce

1. Fedora (or any distro), face enrolled and working via the GUI
2. Create a custom authselect profile based on local, adding auth sufficient libbiopass_pam.so above pam_unix.so in system-auth and password-auth
3. sudo authselect select custom/<profile> --force
4. Run sudo -k && sudo true
5. Observe: IR strobe fires, biopass-helper process spawns (confirmed via ps aux), but authentication always falls through to password

Diagnostic evidence

• journalctl -t biopass-helper — no entries, even with debug: true set in config.yaml
• ~/.local/share/com.ticklab.biopass/debugs/ and /root/.local/share/com.ticklab.biopass/ — both empty/nonexistent after multiple sudo attempts, meaning the helper isn't writing debug output for this path at all
• journalctl -f | grep -iE "biopass|pipewire|v4l2|camera" during a sudo attempt shows only the PipeWire ConditionUser=!root skip messages — no biopass-specific output whatsoever
• SELinux confirmed disabled (getenforce → Disabled), ruling out MAC as a factor
• Module file permissions confirmed correct (-rwxr-xr-x, world-readable)
• authselect current and cat /etc/pam.d/system-auth confirm the PAM stack is correctly wired with libbiopass_pam.so listed first as sufficient

Suggested fixes

1. Have biopass-helper detect when it's running in a root/no-session context (e.g. sudo) and fall back to direct V4L2 device access (/dev/videoN) instead of GstPipeWireSrc, since PipeWire is architecturally unavailable to root.
2. Alternatively, have the helper connect to the invoking (non-root) user's existing PipeWire session/socket rather than trying to start its own as root — similar to how some audio tools bridge into a user's running PipeWire instance from a privileged context.
3. At minimum, log a clear, user-facing error (both to stderr and the debug directory) when PipeWire is unavailable, rather than silently falling through to PAM_AUTH_ERR with zero diagnostic trace — this would have saved significant debugging time.

Environment

• Distro: Fedora (authselect-based, not pam-auth-update)
• PAM integration: manual custom authselect profile (custom/biopass, based on local)
• Auth method: Face (EdgeFace XS, gamma 0.6), enrolled and working via GUI
• debug: true set in config, but no debug output produced for sudo-triggered attempts specifically

---

Feel free to add your actual Biopass version (biopass --version or check the package) and Fedora version before posting — I didn't have those on hand from our conversation.

[phucvinh57]

https://github.com/TickLabVN/biopass/blob/main/CONTRIBUTING.md#contribution-rules

You are to investigate the problem and write the ticket yourself.

[Barnaby-Clifton]

Lol I don't see why I need to understand the problem to report it. But fine, just continue like nothing is wrong.

[phucvinh57]

Apologize for requesting you to investigate the problem. I meant, at least, write report by your own words. AI generates a lot of unnecessary information, which make maintainers confuse while painfully reading the ticket. It will put unnecessary work for us. This project is open soure, we are not customer support team and no one pays for us.

In your case, I guess the problem is to check your PAM config files /etc/pam.d/system-auth. If there is no libbiopass_pam.so there, Biopass has not been triggered any times.

[phucvinh57]

By the way, from AI-generated report, I see that you were using old version. Please install the latest one.

[Barnaby-Clifton]

Yeah I've tried everything. Sorry the ai description was difficult to read.

…

On Thu, 16 Jul 2026, 03:27 Nguyen Phuc Vinh, ***@***.***> wrote: *phucvinh57* left a comment (TickLabVN/biopass#145) <#145 (comment)> Apologize for requesting you to investigate the problem. I meant, at least, write report by your own words. AI generates a lot of unnecessary information, which make maintainers confuse while painfully reading the ticket. It will put unnecessary work for us. This project is open soure, we are not customer support team and no one pays for us. In your case, I guess the problem is to check your PAM config files /etc/pam.d/system-auth. If there is no libbiopass_pam.so there, Biopass has not been triggered any times. — Reply to this email directly, view it on GitHub <#145?email_source=notifications&email_token=AN4H2DK4Z4FFFCQDOLHF6535FA4QRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYG42TIOBUGI2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4987548424>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4H2DNQ4GHF6A2WIDO3PQL5FA4QRAVCNFSNUABFKJSXA33TNF2G64TZHM4DQOJYGYYTQOJZHNEXG43VMU5TIOBXG4YDIMBTGA22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AN4H2DO4FJTOWLV4H3TXK735FA4QRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYG42TIOBUGI2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AN4H2DJBBYK7HZJY3PHB3ET5FA4QRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJYG42TIOBUGI2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>