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
