Repository navigation
Add facial login authentication support for Omarchy #4982
Replies: 8 comments 19 replies
|
the new dell xps panther lake laptops removed fingerprint reader so the only biometric option is face unlock for these laptops |
|
https://github.com/tyvsmith/facelock is a pam module like fprint, so it should be easy to integrate with existing stuff. and it works well with windows hello cameras found in many modern laptops |
|
If there's appetite to add it I can do some exploration with omarchy shell to see what would make sense, and put up a PR for the integration this weekend. |
|
I see your point. After giving it some more thought, I believe that the shell integration should probably live on the Omarchy side, for a couple of reasons:
The PAM setup itself is a slightly different thing, since that would be backend-specific. I imagine that part could live either in an Omarchy setup script, similar to the fingerprint, or in the package installer itself. |
|
There's two user choices for lockscreen customization for testing it to consider. Using facelock with hyprlock as the example to discuss:
There are some users who would prefer to avoid number 2, because it adds another security concern. In that an attacker is aware that the system supports facial auth, and would then attempt to break it directly. So for hyprlock, it's a separate question in the wizard on top of the minimum integration. So for the new lock shell, as long as an empty password would be allowed (with or without modification), it would work once installed. However number 2 is probably where heavier customization and integration into the omarchy install may be desired. For the wiring, it would just need an install (aur, etc..) and then a post install hook that could invoke But I think the question with more consideration would be where to resolve number 2 above within omarchy shell. Is it a separate question on the hook after the install, an opinionated default, or a question/hook that facelock could integrate into the existing wizard. Example of the interactive setup that allows the user to choose models, camera, inference mode, with pam files are modified, daemon mode, TPM support, etc.. This is the flow that the post install hook would invoke from omarchy. |
|
Quick question regarding the lock screen UX: is it possible (or planned) to trigger the camera automatically on lock without pressing Enter first? Thinking of something like Face ID on iPhone where it scans in the background right away. That way you either get unlocked instantly or can just type your password in parallel while it's scanning. Also @tyvsmith, are you planning to open a PR to Omarchy for |
|
@tyvsmith Thanks for the clarification. Good point that just allowing an empty password would be sufficient for the most basic case. I also gave facelock a try in the meantime, so I experienced the setup flow you mentioned myself. Looks good, I think it should integrate well with Omarchy. Regarding point 2, I was actually thinking about taking it a few steps further to solve the issues I've been dealing with over the last few months while using Howdy (but I believe the same would apply to Facelock). So, following your points, the next steps/phases could be: 3. Allow typing your password in parallel while it's scanning@elcokiin also raised this idea. My specific issue is that the IR camera in my Asus Zenbook S14 UX5406AA works poorly in some lighting conditions (for example, with a window or lamp behind me). It seems to be a hardware/firmware issue with auto-exposure - the face ends up basically completely dark. So the current workflow with hyprlock when face detection fails looks like this:
I couldn't find a way to make parallel password typing possible in hyprlock, but that should be possible with a custom lock screen now. It would take the Omarchy-side integration even further than your point 2, though. 4. Start face detection upon opening the laptop lidAlso suggested by @elcokiin. This would take the integration even further, but would move us much closer to the best UX we can get with face unlock. I also think this is currently impossible to do with hyprlock, but should be doable in Omarchy shell. |
|
I had a agent do it, and asked it for precise instruction on how to replicate: Face Unlock (facelock) for Omarchy — Implementation Notes
1. Feature summaryOmarchy's lock screen ships password and fingerprint unlock flows, driven by PAM services This change adds a third unlock method, face unlock, to two surfaces:
2. How it works (architecture)3. Prerequisites
4. Lock screen implementation4.1 PAM serviceFile: 4.2 Shell plugin (cloned)The stock lock plugin lives at omarchy plugin clone omarchy.lock # → ~/.config/omarchy/plugins/storm.lock/Service.qml — new propertiesproperty bool faceAuthenticating: false
property bool faceConfigured: false
readonly property bool authenticating: authenticatingPassword || fingerprintAuthenticating || faceAuthenticatingService.qml — detect facelock (mirrors the fingerprint check)function refreshFaceStatus() {
if (!faceCheckProc.running) faceCheckProc.running = true
}
Process {
id: faceCheckProc
command: ["bash", "-c", "if [[ -f /etc/pam.d/omarchy-lock-face ]] && command -v facelock >/dev/null 2>&1 && facelock list 2>/dev/null | grep -q '\\.onnx'; then echo yes; else echo no; fi"]
stdout: StdioCollector { id: faceCheckStdout; waitForEnd: true }
onExited: {
root.faceConfigured = String(faceCheckStdout.text || "").trim() === "yes"
if (!root.faceConfigured && facePam.active) facePam.abort()
}
}Called from Service.qml — the face flow// Face unlock only runs when explicitly requested — the user presses Enter
// on an empty password field. It never auto-starts on lock.
function startFace() {
if (!lockRequested || !sessionLock.secure || !faceConfigured) return
if (facePam.active || faceAuthenticating) return
faceAuthenticating = true
if (!facePam.start()) {
faceAuthenticating = false
}
}
function handleFaceFinished(result) {
faceAuthenticating = false
if (!lockRequested) return
if (result === PamResult.Success) {
finishUnlock()
} else if (faceConfigured) {
failureMessage = "Face not recognized"
logEvent("face-denied")
runWake()
}
}PamContext {
id: facePam
config: "omarchy-lock-face"
user: root.userName
onCompleted: function(result) {
root.handleFaceFinished(result)
}
onError: function(error) {
root.faceAuthenticating = false
if (root.lockRequested && root.faceConfigured) {
root.failureMessage = "Face not recognized"
root.logEvent("face-denied")
root.runWake()
}
}
}
The LockView wiring in LockView {
...
faceConfigured: root.faceConfigured
onFaceRequested: root.startFace()
...
}LockView.qml — explicit trigger + face iconNew property and signal: property bool faceConfigured: false
signal faceRequested()Enter on an empty field fires onAccepted: {
var submitted = root.passwordText
root.passwordTextEdited("")
if (submitted.length > 0) root.submitPassword(submitted)
else if (root.faceConfigured) root.faceRequested()
}Placeholder hint changes when face is available: readonly property string placeholderText: faceConfigured ? "Password, or press Enter" : "Enter Password"Face icon pinned inside the field's left edge (glyph Text {
id: faceIcon
objectName: "faceIndicator"
anchors.left: parent.left
anchors.leftMargin: inputField.borderLeft + 18
anchors.verticalCenter: parent.verticalCenter
visible: root.faceConfigured
text: ""
color: Color.lock.placeholder
font.family: Style.font.family
font.pixelSize: Math.round(root.fieldFontSize * 1.1)
horizontalAlignment: Text.AlignHCenter
verticalAlignment: Text.AlignVCenter
}The existing 5. Polkit dialog implementation5.1 PAM overridepolkitd authenticates with the PAM service Semantics (identical to the fingerprint convention):
5.2 Shell plugin (cloned)omarchy plugin clone omarchy.polkit # → ~/.config/omarchy/plugins/storm.polkit/PolkitModel.js — face detectionNew function fingerprintConfiguredFromPamConfig(raw) {
return pamModulePresent(raw, "pam_fprintd.so")
}
function faceConfiguredFromPamConfig(raw) {
// Face unlock is available whenever pam_facelock appears in the auth stack,
// with the same lid-gate allowance as the fingerprint stack.
return pamModulePresent(raw, "pam_facelock.so")
}
function pamModulePresent(raw, moduleName) {
var lines = String(raw || "").split("\n")
for (var i = 0; i < lines.length; i++) {
var line = lines[i].replace(/^\s+|\s+$/g, "")
if (!line || line.charAt(0) === "#") continue
if (!line.match(/^auth\s+/)) continue
if (line.indexOf(moduleName) !== -1) return true
}
return false
}(Exports: PolkitAgent.qml — face modeNew state and a combined biometric mode: property bool fingerprintConfigured: false
property bool faceConfigured: false
readonly property bool fingerprintMode: fingerprintConfigured && !laptopClosed && dialogVisible && !responseRequired && !submitted && !errorFlash
readonly property bool faceMode: faceConfigured && !laptopClosed && dialogVisible && !responseRequired && !submitted && !errorFlash
readonly property bool biometricMode: fingerprintMode || faceModeThe FileView {
path: "/etc/pam.d/polkit-1"
watchChanges: true
printErrors: false
onLoaded: root.loadPamConfig(text())
onLoadFailed: {
root.fingerprintConfigured = false
root.faceConfigured = false
}
onFileChanged: reload()
}In biometric mode the card collapses to a square with a centered glyph — fingerprint OpticalGlyph {
anchors.centerIn: parent
width: Math.round(root.fieldHeight * 0.7)
height: width
visible: root.biometricMode
// nf-md-fingerprint while the reader is listening, custom face glyph
// while the camera is looking for a face.
text: root.fingerprintMode ? "\udb80\ude37" : "\udb83\udc7b"
fontFamily: root.fontFamily
fontSize: Math.round(root.fieldHeight * 0.7)
color: root.errorFlash ? Color.polkit.textError : root.accent
}(
6. Step-by-step reproduction# 1. Install & set up facelock (AUR)
yay -S facelock-bin
sudo systemctl enable --now facelock
sudo usermod -aG facelock $USER # then log out/in
sudo facelock add # enroll a face
# 2. Clone the plugins to customize
omarchy plugin clone omarchy.lock
omarchy plugin clone omarchy.polkit
# 3. Write the PAM files (as root)
# /etc/pam.d/omarchy-lock-face → see §4.1
# /etc/pam.d/polkit-1 → see §5.1
# 4. Apply the code from §4.2/§4.3 and §5.2 to the cloned plugins
# 5. Restart the shell and verify
omarchy restart shell
omarchy-shell lock status # expect "face":true7. Verification (real logs)Lock screen — face recognized in ~2.4 s, no password: Polkit ( 8. Caveats & design decisions
9. Proposed upstream integration points
|
|
Hi, @0ncoming-Storm, thanks for working on it! A quick update from my side - I upgraded to Quattro a few days ago and started working on this too, but for now I focused only on one part - the quickshell lock screen, with the following goals:
When that's done, we'll still need to implement the setup process and the polkit dialog. My implementation of the lock integration isn't done yet, but you can check the work in progress on my fork here: https://github.com/mateuszkowalczyk/omarchy/tree/face-unlock As soon as I have this part ready, I can create a PR that we can build upon. What do you think? |
|
Hi everyone! I created this PR — it already integrates face unlock with the Omarchy lock screen, but we still need to implement the setup process and polkit integration. For now, I’ve focused mainly on making the experience as smooth as possible, so, among other things:
We still need to add the setup process to install and configure the backend (most likely Facelock), but there’s only one integration point required: So if you want to give it a try already, it’s just a matter of checking out the PR, installing Facelock (or Howdy), and adding a PAM config like the one mentioned here in Backend contract section. @tyvsmith — if you’re willing to help with testing, or even with implementing the setup part, I’d really appreciate it 🙏 |
|
One more thing to consider about Facelock: I'm not sure whether other devices behave the same way, but I find it a little distracting to have them blinking for that long. Changing the value to @tyvsmith - have you received similar feedback from other users, or tested this on other devices? I'm curious whether the behavior is similar across different hardware. Based on that, we could consider tuning the default config for Omarchy - or Facelock in general, if you think that makes sense. |
|
I'm currently cleaning up some facelock cli footguns for a more seamless experience for omarchy invoking the facelock setup command and skipping some steps (pam integration), and to add an "is-enrolled" command that a non privileged user can call, so we can show it in a user owned lock screen. Once that lands, I'll push the integration prototype up for us to discussion, probably today or tomorrow. For feedback on the timeout, I haven't gotten feedback either way, and am open to tweaking it. The benefit of holding it open is that the camera startup time is a major percentage of the total time taken to authorize and speed to auth has been a top goal of this project, so if you're in a flow that needs you to run sudo multiple times, etc.. it's a benefit to leave it open slightly longer. |
|
I never ran across a situation where I had to auth multiple times in quick succession. I'd say that defaulting the timeout low would make seance, but the user should also have the option to increase it. |
|
thanks, got it, I mostly use face auth on lock screen and keep password for sudo so short release time makes more sense, but yeah we’ll probably need to set default based on what would work best for most users |
|
I've been working on a design for it this morning to close it immediately on a succesful login as the default, leave it warm for a couple seconds in a fail/retry state, and give an option for the user to leave it warm after success as an opt-in. |
|
@mateuszkowalczyk Started a prototype and did some testing on my live quattro system here Also main of facelock has addressed your camera timeout issue. Now defaults to immediately closing the camera after a success. |
|
Hi guys! I think we need a little sync here, as there are currently two parallel implementations:
I think both still need some work (1 seems closer to completion IMO as There's also the question of which face unlock backend to use. 1 uses Howdy, while 2 uses Facelock but makes the backend easily replaceable. I've tried both, and my thoughts are:
There's also howdy-next, suggested by @psynyde, but I haven't tested it myself. Having said that, both implementations and both backends work reasonably well IMO. I'm leaning toward Facelock mainly because of that bright-light issue I had with Howdy. No matter which implementation/backend we choose, I'd suggest making the shell widgets backend-independent. It shouldn't be difficult — we just need to avoid checking for a specific PAM module (like Any thoughts on how we should proceed? |
|
I tried to summarize the work related to the lock screen that I think would be needed if we choose to proceed with either PR. Maybe this will help with the decision. If #5212 is the baseNecessary:
Nice but optional:
If #6863 is the baseNecessary:
Nice but optional:
Tests
|
|
Your PR, #6863, and my followup PR mateuszkowalczyk#1 for some issues on it, is pretty backend agnostic, and should stay that way. I'd probably use that as the base for the shell side. After I updated #7040 yesterday, it lays the groundwork for a mostly backend agnostic implementation (current does prototype facelock, but that's an impl detail easily adjusted as we work on the final version, and it's mostly delegating the work into facelock API calls instead of reinventing the logic). It uses an omarchy owned pam file, omarchy-lock-face, which could use facelock or howdy's pam inside of it. I went looking for how Omarchy already handles multiple implementations of one thing, and browsers, agents and terminals all use the same shape: one script per family with a case over the supported names, shared helpers as functions above it, and the current selection read back from the system rather than a private state file. omarchy-install-browser <chrome|brave|firefox|zen> does per-arm installs with setup_policy_directory and friends shared above the case. omarchy-default-browser maps a name to a desktop id and reports the current one straight out of xdg-settings. omarchy-default-agent does the same against mise. So rather than the provider hook contract I was thinking about, I'd follow that: bin/omarchy-setup-security-face [facelock|howdy] and bin/omarchy-remove-security-face stay the entry points, with a case for the backend. Shared code (provisioning pam.d/omarchy-lock-face, wiring sudo and polkit-1, the messaging) sits above the case, and each arm installs its backend and gets that backend's auth line into the service. Removal needs no argument, since which backend is configured is already readable from the module line in /etc/pam.d/omarchy-lock-face, the same way omarchy-default-browser reads xdg-settings. No new infrastructure, and it matches what's already in bin/. I agree that #5212 has the polkit further along, which would have needed a third PR otherwise, although arguably these are 3 distinct areas, so 3 PRs makes sense. I would suggest carving out the polkit work from this one into something dedicated that's also backend agnostic, and the howdy install logic into an arm of the above as another PR. Note that polkit is already "functional" (at least for facelock) with no changes, just shows the fingerprint icon. Giving us distinct reviewable PRs for:
Caveat on #7040 : It currently uses a main built version temporarily while I fixed some of the feedback here, and locked the API contract to be more final before it's referenced here. If you haven't tried the main built facelock yet, it may resolve your latency issue too (also, it expects liveness frames by default, so turn your head slowly and it'll almost instantly detect). I plan on cutting a stable release today, and updating the PR to reference that. If we want to go with #5212 as the base instead, we'll still want to make the changes to make it agnostic and add a facelock arm alongside the howdy one. One other note is that it seems to do a lot more business logic, like IR camera detection in the setup, we may want to remove that, as cameras have so many quirks, it may end up chasing a lot of complexity that the underlying providers should offer. |
|
Update: #7040 now reflects that shape mentioned. |
|
Just thought I'd share, I made a plugin that implements howdy that auto fires on system wake https://github.com/tslove923/omarchy-howdy-face-unlock. HANCORE had some great feedback about keeping the QML safe omacom/omarchy-plugin-marketplace#2277. Just in case there's something there you want to pull in upstream. |
|
Here is my lock screen and polkit plugins. They have been working very well for me for about a month now: they both need facelock to be configured manually. |
|
and a pull request to a popular lock screen addon: SirJul1337/omarchy-lock-explorer#21 |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Would Omarchy be open to supporting optional facial authentication, similar to the existing fingerprint and FIDO2 setup flows?
Why I’m asking
From what I can tell, Omarchy already has support around:
That makes facial authentication feel like a possible fit in the same security/setup area, at least as an optional feature.
Possible direction
I’m not suggesting this as a default. I’m thinking of an optional setup flow, for example:
omarchy-setup-faceQuestions
sudo/polkit, instead of full login/unlock flows?Note
I searched the repository and found existing fingerprint/FIDO2-related support, but I didn’t find an obvious facial-auth implementation.
All reactions