Dark mode support causes xdg-desktop-portal to run and start gnome-keyring, which breaks user keyring setup
This is an upstream report of https://bugzilla.redhat.com/show_bug.cgi?id=2066424 . We found in recent Fedora 36 builds that the keyring of a user created in g-i-s is not set up properly; the keyring password is not set to the user's password, and so it is not unlocked on login and cannot be unlocked manually as the user does not know the password.
This ultimately turns out to be caused by the dark mode support - !140 (merged) . It somehow results in all the xdg-desktop-portal stuff starting up when g-i-s runs, which results in gnome-keyring
being run (to provide the org.freedesktop.impl.portal.Secret
implementation). I'm guessing that this other instance of gnome-keyring
competes with the one that g-i-s starts directly - probably stopping it from owning the dbus interface - and that breaks the setting of the keyring password. Here's a log extract showing the highlights:
Mar 21 18:37:16 localhost-live /usr/libexec/gdm-wayland-session[1036]: dbus-daemon[1036]: [session uid=985 pid=1036] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.61' (uid=985 pid=1435 comm="/usr/libexec/gnome-initial-setup" label="system_u:system_r:xdm_t:s0-s0:c0.c1023")
...
Mar 21 18:37:17 localhost-live /usr/libexec/gdm-wayland-session[1036]: dbus-daemon[1036]: [session uid=985 pid=1036] Activating service name='org.freedesktop.secrets' requested by ':1.66' (uid=985 pid=1495 comm="/usr/libexec/xdg-desktop-portal" label="system_u:system_r:xdm_t:s0-s0:c0.c1023")
Mar 21 18:37:17 localhost-live gnome-keyring-daemon[1549]: couldn't access control socket: /run/user/985/keyring/control: No such file or directory
Mar 21 18:37:17 localhost-live gnome-keyring-d[1549]: couldn't access control socket: /run/user/985/keyring/control: No such file or directory
Mar 21 18:37:17 localhost-live /usr/libexec/gdm-wayland-session[1036]: dbus-daemon[1036]: [session uid=985 pid=1036] Successfully activated service 'org.freedesktop.secrets'
...
Mar 21 18:37:17 localhost-live gnome-initial-s[1435]: Starting gnome-initial-setup
Mar 21 18:37:17 localhost-live gnome-initial-s[1435]: Production mode: changes will be saved to disk
Mar 21 18:37:17 localhost-live gnome-keyring-daemon[1561]: couldn't set environment variable in session: GDBus.Error:org.gnome.SessionManager.NotInInitialization: Setenv interface is only available during the DisplayServer and Initialization phase
Mar 21 18:37:17 localhost-live gnome-keyring-daemon[1561]: another secret service is running
...
Mar 21 18:37:35 localhost-live gnome-initial-s[1435]: Failed to change keyring password: GDBus.Error:org.freedesktop.Secret.Error.NoSuchObject: The collection does not exist
note that pid 1549 there is the extra gnome-keyring-daemon
process run by xdg-desktop-portal. Its full command line is /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
. pid 1561 is the gnome-keyring-daemon
that g-i-s launches directly, the one it wants to talk to. Its full command line is gnome-keyring-daemon --unlock
.
I verified that if I kill the gnome-keyring-daemon
process launched by xdg-desktop-portal (you can do this from a systemd debug shell) before proceeding through g-i-s, the bug goes away - the Failed to change keyring password: GDBus.Error:org.freedesktop.Secret.Error.NoSuchObject: The collection does not exist
error is not printed, and the keyring password is set correctly and unlocked on user login.
I then bisected the bug a bit by installing old Fedora builds. 42-beta worked fine, but 42-rc has the bug. So I looked through the commit history and saw that the dark mode support is the only significant one between 42-beta and 42-rc, so I did a scratch build with that change reverted, and sure enough, it doesn't have the bug. There is no extra gnome-keyring
process running when g-i-s starts up, no log messages about xdg-desktop-portal-related stuff, and the keyring is set up correctly.