GIO security hardening causing gnome-keyring to regress when session bus is provided by dbus-launch (dbus-x11)

Debian's glib2.0 package, version >= 2.66.4-2, applies patches from the glib-2-66 branch up to 872181c4.

We've had a report that this version causes gnome-keyring to regress, failing to unlock the login keyring. It appears this is triggered by !1862 (merged).

This seems to be because gnome-keyring-daemon is setcap, so it gets the AT_SECURE flag set on it, making GIO refuse to use environment variables. We've seen this before in libdbus (when we were mitigating CVE-2012-3524 and gnome-keyring had not yet been ported to GDBus) - which is why libdbus only checks for euid != ruid, not for AT_SECURE, even though that's theoretically wrong and checking for AT_SECURE would be a stronger mitigation.

When the session bus is provided by the systemd --user service dbus.service (the dbus-user-session Debian package) with a socket at $XDG_RUNTIME_DIR/bus, gnome-keyring-daemon still works, because we do not check for AT_SECURE before retrieving the XDG_RUNTIME_DIR environment variable to form $XDG_RUNTIME_DIR/bus. I believe dbus-broker would have the same behaviour, because it is a reimplementation of this mode, and so also uses $XDG_RUNTIME_DIR/bus.

However, when the session bus is provided by dbus-launch (the dbus-x11 Debian package) with a socket at /tmp/dbus-XXXXXXXXXX, gnome-keyring does not unlock or start successfully, because there is no mechanism to find that socket that remains enabled while it is AT_SECURE.