Skip to content

feat(setup): detect display managers and screen lockers; offer per-service opt-in#43

Merged
tyvsmith merged 2 commits into
mainfrom
feat/pam-setup-detect-display-managers-and-lockers
May 24, 2026
Merged

feat(setup): detect display managers and screen lockers; offer per-service opt-in#43
tyvsmith merged 2 commits into
mainfrom
feat/pam-setup-detect-display-managers-and-lockers

Conversation

@tyvsmith
Copy link
Copy Markdown
Owner

Summary

  • Replaces the hardcoded [sudo, polkit-1, hyprlock] PAM service list with a PAM_CANDIDATES table filtered at runtime by /etc/pam.d/<service> existence
  • Adds five new services: swaylock, kscreenlocker_greet, gdm-password, sddm, lightdm
  • Changes the wizard flow from a single MultiSelect to individual Confirm prompts, showing the recommended default per service
  • Non-interactive mode automatically uses each candidate's default_enabled value

Services × Category × Default × Rationale

Service Category Default Rationale
sudo PrivilegeEscalation YES Low-risk; password fallback always available
polkit-1 PrivilegeEscalation YES Low-risk; password fallback always available
hyprlock LockScreen YES Safe fallback; worst case is typing password
swaylock LockScreen YES Safe fallback; worst case is typing password
kscreenlocker_greet LockScreen YES Safe fallback; worst case is typing password
gdm-password DisplayManager NO Login-screen lockout risk without recovery access
sddm DisplayManager NO Login-screen lockout risk without recovery access
lightdm DisplayManager NO Login-screen lockout risk without recovery access

Intentionally excluded (never offered)

  • system-auth (Arch) / common-auth (Debian): shared stacks — would spread face auth to passwd, su, chsh, chfn, etc.
  • login: TTY login; camera may not be initialized at boot
  • su, passwd, chsh, chfn: credential/privilege-change tools that must require a real password
  • Any unknown service: only services explicitly listed in PAM_CANDIDATES are offered

Note on racing PRs

PR #1 (uninstall cleanup) and PR #2 (PAM confirmation prompt) are racing. This PR may have minor conflicts with PR #2 if both touch the per-service iteration loop; resolve at merge time.

Test plan

  • cargo build --workspace — clean, no warnings
  • cargo test -p facelock-cli — 69 tests pass, including:
    • commands::setup::tests::detect_candidates_filters_by_presence
    • commands::setup::tests::no_excluded_services_in_candidates
  • cargo clippy --workspace -- -D warnings — clean
  • On a system with only sudo and hyprlock in /etc/pam.d/: only those two are offered
  • On a system with sddm present: sddm is offered with default NO
  • Non-interactive mode (facelock setup --non-interactive): defaults applied without prompts
  • cargo run --bin facelock -- setup --help — still works

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

Copilot AI review requested due to automatic review settings May 24, 2026 04:05
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the facelock setup wizard to detect supported PAM services dynamically (based on /etc/pam.d/<service> presence) and to configure each service via per-service opt-in prompts, with safe defaults applied automatically in non-interactive mode.

Changes:

  • Replace the hardcoded PAM service list with a PAM_CANDIDATES table filtered at runtime.
  • Switch from a single MultiSelect prompt to per-service Confirm prompts (and apply defaults in non-interactive mode).
  • Add unit tests for candidate detection and explicitly excluded services; add tempfile as a dev-dependency for tests.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File Description
crates/facelock-cli/src/commands/setup.rs Adds PAM candidate detection + per-service prompting, and tests for filtering/exclusions.
crates/facelock-cli/Cargo.toml Adds tempfile as a dev-dependency for new unit tests.
Cargo.lock Locks the newly added tempfile dev-dependency.
Comments suppressed due to low confidence (2)

crates/facelock-cli/src/commands/setup.rs:1441

  • Grammar in this description is off: "declining recommended" is missing a verb (e.g., "declining is recommended").
        description: "SDDM login screen (KDE) \u{2014} declining recommended unless you have recovery access",

crates/facelock-cli/src/commands/setup.rs:1447

  • Grammar in this description is off: "declining recommended" is missing a verb (e.g., "declining is recommended").
        description: "LightDM login screen (Ubuntu/Xfce/Mint) \u{2014} declining recommended unless you have recovery access",

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +947 to +951
Confirm::new()
.with_prompt(&prompt)
.default(candidate.default_enabled)
.interact()?
};
Comment on lines +1435 to +1447
description: "GDM login screen (GNOME) \u{2014} declining recommended unless you have recovery access",
default_enabled: false,
},
PamCandidate {
service: "sddm",
category: PamCategory::DisplayManager,
description: "SDDM login screen (KDE) \u{2014} declining recommended unless you have recovery access",
default_enabled: false,
},
PamCandidate {
service: "lightdm",
category: PamCategory::DisplayManager,
description: "LightDM login screen (Ubuntu/Xfce/Mint) \u{2014} declining recommended unless you have recovery access",
tyvsmith added a commit that referenced this pull request May 24, 2026
…DM descriptions

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tyvsmith and others added 2 commits May 23, 2026 22:02
…rvice opt-in

Replaces the hardcoded [sudo, polkit-1, hyprlock] list with a
PAM_CANDIDATES table that is filtered at runtime by /etc/pam.d/<service>
existence, then presented to the user one service at a time via
dialoguer::Confirm.

New services covered:
- swaylock (Sway/wlroots screen lock) — default YES
- kscreenlocker_greet (KDE Plasma screen lock) — default YES
- gdm-password (GNOME display manager login screen) — default NO
- sddm (KDE display manager login screen) — default NO
- lightdm (Ubuntu/Xfce/Mint display manager login screen) — default NO

Default-YES rationale: screen lockers have safe password fallback; worst
case is an extra Enter keypress.

Default-NO rationale: display manager login screens lock users out of the
system if face auth fails and they have no other recovery path; opt-in
should be explicit.

Explicit non-targets (never offered, even if /etc/pam.d/<name> exists):
- system-auth / common-auth: shared stacks that would spread face auth to
  passwd, su, chsh, chfn, etc.
- login: TTY login; camera may not be initialized at boot.
- su, passwd, chsh, chfn: credential/privilege-change tools that must
  require a real password.

Wizard flow change: replaces MultiSelect-all-at-once with individual
Confirm prompts so the user sees the default recommendation per service.
Non-interactive mode uses each candidate's default_enabled value.

Adds two unit tests:
- detect_candidates_filters_by_presence: verifies candidates_in() against
  a TempDir; only services with a matching file are returned.
- no_excluded_services_in_candidates: asserts the excluded service list
  never appears in PAM_CANDIDATES.

Adds tempfile as a dev-dependency of facelock-cli.

Note: PR #1 (uninstall cleanup) and PR #2 (PAM confirmation prompt) are
racing. This PR may have minor conflicts with #2 if both touch the
per-service iteration; resolve at merge time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…DM descriptions

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@tyvsmith tyvsmith force-pushed the feat/pam-setup-detect-display-managers-and-lockers branch from f14da04 to 68ebc20 Compare May 24, 2026 05:02
@tyvsmith tyvsmith merged commit ac93c3a into main May 24, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants