Bug#994961: glib2.0: gnome-keyring unable to unlock login keyring on some systems since GLib 2.70.0-1

[Simon McVittie]

Control: reassign 994961 src:glib2.0,gnome-keyring
Control: found 994961 glib2.0/2.70.0-1
Control: found 994961 gnome-keyring/3.36.0-1
Control: tags 994961 + bookworm sid
Control: forwarded 994961 https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/77

On Thu, 23 Sep 2021 at 22:33:06 -0700, Francois Marier wrote:
> It looks like Bug #981420 was reintroduced in 2.70.0-1, as foreshadowed by
> the 2.66.4-4 changelog entries

Yes, the deadline set by the upstream GLib maintainers was reached and
the security hardening has been reinstated.

To work with this version, the gnome-keyring package needs to stop
making gnome-keyring-daemon setcap (which I thought it already had,
but apparently not...)

User processes are allowed to lock a reasonable amount of memory by
default, which makes CAP_IPC_LOCK a lot less necessary than it used to be.
On typical Debian systems, they are allowed to lock an *unreasonable*
amount of memory by default due to unintended interactions between PAM
and systemd, which is a denial-of-service risk for systems with lots of
users (#976373) but works in our favour here.

> I am no longer able to start gnome-keyring-daemon:
> 
>   $ gnome-keyring-daemon -r
>   ** Message: 14:57:35.890: couldn't connect to dbus session bus: Cannot spawn a message bus when setuid
>   ** Message: 14:57:35.890: Replacing daemon, using directory: /run/user/1000/keyring
>   GNOME_KEYRING_CONTROL=/run/user/1000/keyring
>   SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
...
> I do have the dbus-user-session package installed.

I'm surprised by this. It's clearly still picking up XDG_RUNTIME_DIR
from the environment, so I would have expected it to be able to connect
to $XDG_RUNTIME_DIR/bus (arguably that's a bug, in that it should not be
trusting the environment at all when run with capabilities, but it's
necessary as long as gnome-keyring-daemon is setcap).

Do you have a socket at $XDG_RUNTIME_DIR/bus owned by your uid?

What is the status of the session bus? (`systemctl --user status dbus.service`
and `systemctl --user status dbus.socket`)

"Cannot spawn a message bus when setuid" is shorthand, and not 100%
accurate: it really means "when setuid, setgid, setcap, after an AppArmor
transition involving modes U, P or C, or with any other elevated privilege"
but that seems too long for an error message.

    smcv