Public bug reported: ## Environment - Ubuntu 26.04.1 LTS (codename: resolute) - gdm3: 50.1-0ubuntu0.1 (upgraded from 46.2-1ubuntu1~24.04.9 on 2026-09-04 15:40) - libpam-gnome-keyring: 50.0-1 (upgraded from 46.1-2ubuntu0.2 on 2026-09-04 15:55) - gnome-keyring: 50.0-1 - libpam-runtime: 1.7.0-5ubuntu3.2 - Session type: GDM Wayland, display manager service `gdm-password` - Hardware: Lenovo IdeaPad Gaming 3 15ARH7
## Summary After the gdm3/gnome-keyring/libpam-gnome-keyring upgrade from the 46.x to 50.x series, the login (GNOME) keyring no longer auto-unlocks at login. Every session requires manually re-entering a password into an interactive "Unlock/Create keyring" dialog, and the collection created this way never receives the special `CKA_G_LOGIN_COLLECTION` treatment PAM expects, so the problem repeats every single login. ## Steps to reproduce 1. Fresh login via GDM (`gdm-password` PAM service) on a system with gdm3/libpam-gnome-keyring 50.x. 2. Observe `journalctl` shows: `gkr-pam: couldn't unlock the login keyring.` at session-open, every time, regardless of whether `~/.local/share/keyrings/` is empty or contains a previously-created `Default.keyring`. 3. Any app requesting a secret (browser, `python3-keyring`'s SecretService backend, ProtonVPN's Linux client, etc.) triggers an interactive "Create/Unlock keyring" dialog instead of a silent PAM-driven unlock. 4. Inspect the running session's `gnome-keyring-daemon` process control directory: `ls -la /run/user/<uid>/keyring/` shows only a `pkcs11` socket — **no `control` socket is ever created** by the daemon instance that PAM/`gdm-password`'s session phase spawns normally. 5. Manually running `gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets --control-directory=/run/user/<uid>/keyring` from an already-logged-in session DOES create a `control` socket, but logs: ``` couldn't set environment variable in session: GDBus.Error:org.gnome.SessionManager.NotInInitialization: Setenv interface is only available during the Initialization phase another secret service is running ``` — i.e. it cannot take over the `org.freedesktop.secrets` D-Bus name from the original daemon, so it becomes a second, disconnected daemon instance. `gnome-keyring-daemon --login` run afterwards attaches to this orphaned instance instead of the real session daemon, so `login.keyring` still never appears where the live SecretService/PAM expects it. ## PAM configuration investigated (and a real, separate bug fixed along the way) `/etc/pam.d/gdm-password` (as shipped by gdm3 50.1-0ubuntu0.1) places: ``` @include common-auth auth optional pam_gnome_keyring.so ``` Because `common-auth` (from libpam-runtime, with faillock enabled) contains: ``` auth [success=2 default=ignore] pam_unix.so nullok auth [success=1 default=ignore] pam_sss.so use_first_pass auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc ``` a successful `pam_unix.so` jumps straight to the `sufficient pam_faillock.so authsucc` line, which **short-circuits the rest of the auth stack — including the `pam_gnome_keyring.so` line that comes after the `@include`**. This alone causes `gkr-pam: no password is available for user` at auth time. Reordering to run `pam_gnome_keyring.so` immediately after `pam_unix.so` succeeds (before the `sufficient` line) fixes *that* symptom (auth-phase password capture now works, log changes from "no password is available" to "couldn't unlock the login keyring"), but the daemon-side control- socket bug above remains and blocks the rest of the flow. Both issues need fixing for this to actually work end to end — the ordering bug affects every GDM-based Ubuntu system with faillock enabled in `common- auth`, independent of the daemon bug. ## Expected behavior On a fresh login, the daemon started for the session should create both its `pkcs11` and `control` sockets, and `pam_gnome_keyring.so`'s session-phase `auto_start` call should be able to discover it and either unlock an existing `login.keyring` (created with the login password) or create one silently, matching pre-46→50 upgrade behavior. ## Actual behavior The session's own `gnome-keyring-daemon` instance never creates a `control` socket, so it can never be discovered by any `--start`/`--login`/`--unlock` PAM helper invocation. Users are stuck manually unlocking a generic "Default" SecretService collection every session, which is never recognized by PAM as the login keyring. ## Related upstream reports - https://discourse.gnome.org/t/gkr-pam-couldnt-unlock-the-login-keyring/29104 - https://github.com/canonical/authd/issues/944 Maybe you can investigate why `gnome-keyring-daemon`'s normal session-startup invocation (via `pam_gnome_keyring.so auto_start` / systemd user service) omits creating the `control` socket, while a manual `--replace` invocation does create it. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: gnome-keyring 50.0-1 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: Unity Date: Sat Sep 5 10:27:21 2026 InstallationDate: Installed on 2025-09-13 (356 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) SourcePackage: gnome-keyring UpgradeStatus: Upgraded to resolute on 2026-09-04 (1 days ago) ** Affects: gnome-keyring (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/2166548 Title: gnome-keyring session daemon fails to create control socket, breaking PAM login-keyring auto-unlock To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/2166548/+subscriptions -- desktop-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
