auth: add Visage face authentication module#1010
Conversation
| std::atomic<bool> m_bAbort{false}; | ||
| std::atomic<bool> m_bAuthenticated{false}; |
There was a problem hiding this comment.
This is the "legacy" way that hypr* named member vars. Can you change it to the new "m_" format?
At some point I would like to bulk change all of the var names, but I don't want to disrupt open PRs...
|
|
||
| void CVisage::init() { | ||
| m_sPrompt = m_sReadyMessage; | ||
| m_thread = std::thread([this] { workerLoop(); }); |
There was a problem hiding this comment.
The fingerprint auth implementation doesn't need it's own thread, because it uses async method calls.
Is there a reason visage needs a thread?
I would prefer if visage would also handle it like that.
But for this to work, we need to pull out the dbus connection object from fingerprint (add g_dbus) so that we can reuse the same connection here and only need one connection.
There was a problem hiding this comment.
Let me know if you would be up to pull out the dbus connection from fingerprint. If not I can do it and you can rebase your branch on top of it.
2 participants
Adds a parallel face-auth backend that talks directly to Visage's system D-Bus interface (
org.freedesktop.Visage1) instead of going throughpam_visage.so. This mirrors the approach taken for fingerprint in #514: PAM modules are evaluated as soon aspam_authenticatestarts, which means the face check fires the instant the lock appears and unlocks immediately if a face is in front of the camera. Direct D-Bus integration lets us add a smallstart_delayafter lock and gate retries on a condvar so submitting input nudges a fresh attempt.A worker thread polls
Verify(username)and on a match callsg_pAuth->enqueueUnlock(). PAM continues to run in parallel as before, so password unlock works unchanged.Disabled by default. Enable with
auth.visage.enabled = 1. Other knobs areready_message,retry_delay(default 500 ms), andstart_delay(default 2000 ms).Verify calls are bounded with
withTimeout(30s)so a hung daemon can't deadlockterminate(). On D-Bus errors the worker backs off exponentially up to 5 s and never permanently gives up — visaged commonly takes 30–90 s to come back after a hibernate resume on Surface devices, and the user may also be waiting onvisage-resume.serviceto restart it. If visaged isn't running at hyprlock start, the worker retries the connection every 2 s.I did not add a
PrepareForSleephandler like fingerprint has. The retry loop recovers organically once visaged is reachable again, so it didn't seem worth the extra dbus connection. Happy to add it if you'd rather mirror the fingerprint structure exactly.