Bug#981420: libglib2.0-0: gnome-keyring unable to unlock login keyring

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/2305

On Sun, 31 Jan 2021 at 18:53:09 -0500, Charles Malaheenee wrote:
> In journalctl there are a lot messages from systemd or dbus-daemon, like "dbus-daemon[970]: [session uid=1000 pid=968] Successfully activated service 'org.mate.panel.applet.ClockAppletFactory'" or "systemd[902]: Started Sound Service."

That's fine, as long as they aren't reporting failures.

> (version 2.66.4-3, bug appears)
> Jan 30 14:26:13 big-pc gnome-keyring-daemon[920]: couldn't connect to dbus session bus: Cannot spawn a message bus when setuid
> (version 2.66.4-3+revert981420targeted, no bug)
> Jan 31 18:31:57 big-pc gnome-keyring-daemon[924]: GLib-GIO: Not suppressing use of DBUS_SESSION_BUS_ADDRESS because not setuid, even though AT_SECURE

Right. So my theory was at least partially correct: gnome-keyring-daemon
is refusing to connect to the D-Bus session bus, because while not
actually setuid, it has elevated privileges that its caller does not
have (CAP_IPC_LOCK), and therefore does not (and should not!) trust the
DBUS_SESSION_BUS_ADDRESS that it inherits from its caller.

Do you have the dbus-user-session package installed? If you don't, does
installing that package with one of the affected versions of GLib (such
as 2.66.4-3) make this regression disappear?

If you rely on the ability to have a separate D-Bus session bus per
X11 display for the same uid, then you can't use dbus-user-session
permanently, because it represents a different model where each uid has
only one instance of the D-Bus session bus. If you have no particular
opinion on whether the session bus should be per uid or per X11 display,
then dbus-user-session is what I would recommend.

    smcv