pam_oo7: start daemon on session open even without PAM_AUTHTOK stash

[kitten-lily]

Use case

When using FIDO2/hardware key authentication (pam_u2f), PAM_AUTHTOK is never set — the FIDO2 PIN is verified internally by libfido2 and not propagated to PAM item storage. pam_u2f does not call pam_set_item(PAM_AUTHTOK, ...).

With the current pam_oo7.so auto_start behaviour, if no stash exists (PAM_AUTHTOK was never set), pam_sm_open_session returns PAM_SUCCESS immediately without contacting the daemon:

if ret != PAM_SUCCESS || password_ptr.is_null() {
    tracing::debug!("No stashed password found in session");
    return PAM_SUCCESS;
}
// send_secret_to_daemon never called

The oo7 daemon is not started at all. On FIDO2 login the daemon starts only on the first D-Bus access (via D-Bus session activation), and if the default collection has a password the user sees a keyring unlock prompt from whatever app first accesses secrets.

Requested behaviour

Two related changes:

1. Start daemon on session open even without a stash.
pam_sm_open_session with auto_start should contact the daemon to start it (without attempting an unlock) even when no password stash is present. This ensures the daemon is running early in the session without waiting for first D-Bus use.

2. Support auto-opening an empty/unprotected default collection.
If a collection has no password (empty master password or is marked as not-encrypted), the daemon should be able to open it automatically on start without requiring a stash. This would allow FIDO2 logins to have seamless secret access — trade-off is secrets at rest are unencrypted (same as gnome-keyring's behaviour on many distros when users clear the keyring password).

Current workaround

None. FIDO2 users must either accept a delayed keyring unlock prompt on first secrets access, or use a password-based fallback auth method.

Context

• pam_u2f (Yubico, https://github.com/Yubico/pam-u2f) does not set PAM_AUTHTOK
• pam_sm_authenticate in pam/src/lib.rs already handles null authtok gracefully (returns PAM_SUCCESS) — the gap is the session open side
• This pattern affects any PAM stack using a sufficient hardware auth module before pam_unix

[kitten-lily]

I'm sorry if LLM-created issues are unwanted.
Claude filed this for me while I had it investigate auto unlock for me but it is a genuine issue I am interested in resolving.
I've updated my local guidance but this is is still quite embarassing. 😳

[bilelmoussaoui]

the daemon is nowadays autostarted by a systemd service, no longer started by the pam module, it instead starts a oo7-daemon-login binary helper

[bilelmoussaoui]

But in any case we don't have tests verifying that an empty secret works, so that is what i would suggest you to look into first

[bilelmoussaoui]

with #505, being merged, we should properly handle unencrypted keyrings. I will let you take care of testing that with your FIDO2/hardware key authentication