SecureEye lets you unlock a session and approve sudo on Linux by looking at the camera. It started as a fork of Howdy. Howdy’s PAM module launches its Python recognition script as root on every login attempt, so the whole recognition stack runs inside the authentication path. Most of my work on SecureEye went into moving it out.
What is left in PAM is a small C++ module. It checks whether face login applies at all, sends one request to a recognition daemon and waits for the answer under a hard deadline. Any outcome it cannot verify counts as a failure, and the password prompt takes over.
It is alpha software. Keep a password set up; face login is meant to sit in front of it.
sudo / loginpam_secureEye.soauthd.socksecureeye-authdcamerapam_secureEye.so · C++
Runs inside the PAM stack. Pre-checks run first: SecureEye disabled, an SSH session, a closed lid, or no enrolled face model. Then it sends a single request over the socket and polls with a deadline. No Python is linked in.
/run/secureeye/authd.sock · mode 0660
Length-prefixed JSON frames: a 4-byte big-endian length, then at most 4096 bytes of UTF-8. One request and one response per connection, with a strict protocol version. Requests carry the user, PAM service, TTY and a deadline_ms between 100 ms and 30 s.
secureeye-authd · Python · systemd
Runs as the unprivileged secureeye user with only the video group added. Holds the camera, the detector and the face models. Its own worker deadline sits 700 ms inside the client’s, so it replies before PAM gives up on it.
An attempt reads camera frames for up to timeout seconds (4 by default). Each frame is equalised with CLAHE. Frames that are too dark are skipped, which matters with IR cameras whose emitters flash, and the rest are scaled down to at most 320 px high.
Each detected face is encoded and compared with the user’s enrolled encodings by Euclidean distance. The nearest one has to fall under the certainty threshold, 0.35 by default. The detector is built once and cached in the daemon, so only the first attempt after a restart pays for loading the models.
After a match, optional “rubberstamp” checks can run before the login is accepted. One asks the user to nod, another waits for a hotkey. They are off by default.
How each outcome maps to a PAM return code. With the module set to auth sufficient, both non-success results drop through to the next module, which is normally the password prompt.
| When | PAM result | Effect |
|---|---|---|
| SecureEye disabled, SSH session, lid closed, no face model | PAM_AUTHINFO_UNAVAIL | Skipped before the camera turns on |
| Face matched | PAM_SUCCESS | Logged in |
| No match before the timeout, frames too dark, bad device, rubberstamp failed | PAM_AUTH_ERR | Password prompt |
| Daemon unreachable, IPC timeout, malformed frame, version mismatch | PAM_AUTH_ERR | Password prompt |
All three distributions get the same single secure-eye package. It holds the PAM module, the daemon, the recognition runtime and the secureEye CLI. The recognition backends are ordinary distribution packages instead of a bundled virtualenv, so the daemon runs on the system Python and nothing has to be rebuilt after a Python upgrade.
sudo add-apt-repository ppa:vhrabar/tools
sudo apt update
sudo apt install secure-eyeEnables the PAM profile and starts the daemon on install.
sudo dnf copr enable vhrabar/SecureEye
sudo dnf copr enable vhrabar/python-extras
sudo dnf install secure-eye
sudo systemctl enable --now secureeye-authd.serviceAdd pam_secureEye.so to PAM yourself, through an authselect profile.
paru -S secure-eye
sudo systemctl enable --now secureeye-authd.serviceAdd auth sufficient pam_secureEye.so to /etc/pam.d/sudo or system-auth.
device_path at your camera with sudo secureEye config, then restart the daemon.sudo secureEye add.sudo -i.The README covers the PAM setup for each distribution step by step. README
One release workflow runs the tests and builds and install-tests the deb, RPM and Arch packages. If those pass, it publishes to the Launchpad PPA, Copr and the AUR. CHANGELOG.md is the only place release notes are written; the Debian and RPM changelogs and the GitHub release text are generated from it.
.copr/Makefile resolved the release version with git describe while make parsed the file, which happens before the recipe installs git. The version came out empty and set-package-version.sh aborted. It is now resolved inside the recipe, after git is installed, and a clone with no reachable tag fails with a message that says so rather than with a blank version.secure-eye package on Debian, RPM and Arch, replacing libpam-secureeye, secureeye-authd and the transitional metapackage. Existing installs are swapped automatically on upgrade.python3-mediapipe (amd64/x86_64 only) and python3-dlib, from ppa:vhrabar/tools on Ubuntu and copr:vhrabar/python-extras on Fedora. Select one with detector_backend in /etc/secureEye/config.ini.secureEye launcher run on the system Python interpreter, so nothing has to be rebuilt after a Python upgrade. The systemd unit and the launcher now use the interpreter meson was configured with rather than a hardcoded virtualenv path..deb or .rpm attachments. Install from the PPA, COPR or the AUR instead.secure-eye.CHANGELOG.md is the single source of truth for release notes. scripts/set-package-version.sh renders a release's section into the Debian and RPM changelogs, and scripts/changelog-section.sh extracts it for the GitHub release body.secureeye-authd.service has to be enabled manually. The README claimed installation enabled it.set command.First Arch release: SecureEye now packages and installs on Arch-like distributions, alongside the existing Debian/Ubuntu/RPM support.
First RPM release: SecureEye now packages and installs on Fedora and RHEL-family distributions, alongside the existing Debian/Ubuntu support.
libpam-secureeye (PAM module), secureeye-authd (daemon plus the Python recognition runtime), and the secure-eye transitional metapackage.vhrabar/SecureEye): install on Fedora with dnf copr enable vhrabar/SecureEye && dnf install secure-eye.scripts/build-rpm.sh, to build the RPMs in a Fedora container.python3-dlib and there is no prebuilt aarch64 wheel, the dlib recognition wheel (pinned to 20.0.1) is compiled from source during the RPM build.Showing the latest 5 of 6 releases. Full changelog