Reuse D-Bus sessions across login sessions

d-bussession

I access a machine through multiple login sessions. The sessions' lifetimes may or may not overlap. In my case, these login sessions are currently always over SSH, but I would prefer to handle local sessions too.

I sometimes need D-Bus in these sessions, and I want to share the same D-Bus session across these login sessions, in order to use GVFS.

What is the recommended way to do this? I don't want to break any use of D-Bus that I may not be aware of. I've considered using

export $(dbus-launch --autolaunch $(cat /var/lib/dbus/machine-id))

but (as of Ubuntu 12.04) this doesn't seem right:

this requires an X session, but my SSH sessions may or may not be forwarding an X display, and even the ones that are don't have the same $DISPLAY;
if no X display is available, dbus-launch complains that “Autolaunch error: X11 initialization failed.” and doesn't start a daemon;
the dbus-launch man page states that “The --autolaunch option is considered an internal implementation detail (…). There's no real reason to use it outside of the libdbus implementation anyhow.”

Does dbus-launch or another tool in the D-Bus suite support automatically detecting a running dbus-daemon and connecting to it? The necessary information is in ~/.dbus/session-bus/$(cat /var/lib/dbus/machine-id)-${DISPLAY#*:} if D-Bus is started with an X connection, but doesn't seem to be stored anywhere if no X connection is available.

Should I cobble my own D-Bus session file? If I do, should I use a file in the ~/.dbus/session-bus directory? Is the path /var/lib/dbus/machine-id reliable and portable?

Best Answer

DBus makes sharing the settings for the dbus daemon a little tricky.

For my setup, the settings from dbus-launch --sh-syntax are saved in a file that is source by the .bash_rc. The downside of this is that, after every reboot, that process is performed manually.

However, it should be very simple to check for an existing DBus daemon. Let's say the settings file is at $HOME/.dbus_settings:

need_start=1

if [ -r "$HOME/.dbus_settings" ]
then
    . "$HOME/.dbus_settings"
fi

if [ -n "$DBUS_SESSION_BUS_PID" ]
then
    if kill -0 "$DBUS_SESSION_BUS_PID" 2>/dev/null
    then
        need_start=0  # Found one
    fi
fi

if [ "$need_start" -ne 0 ]
then
    dbus-launch --sh-syntax >"$HOME/.dbus_settings"
    . "$HOME/.dbus_settings"
fi

Without the --autolaunch option, I don't believe an X windows connection is needed.

Related Solutions

D-Bus Security – Understanding D-Bus Authentication and Authorization

D-Bus isn't using the magic cookie file here; it's passing credentials over the UNIX domain socket (SCM_CREDENTIALS).

The magic cookie file is only one of several D-Bus authentication mechanisms. D-Bus implements a SASL-compliant interface (see RFC4422) to support a wide range of authentication mechanisms. One of these mechanisms is called "EXTERNAL" auth, and it means that the transport channel itself should be used to guarantee authentication. At least in the case of D-Bus over UNIX sockets, this appears to be the first authentication mechanism that is tried.

From the D-Bus spec:

Special credentials-passing nul byte

Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client.

A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only.

The credentials sent along with the nul byte may be used with the SASL mechanism EXTERNAL.

If you strace an instance of dbus-daemon, you can see that when you connect to it, it checks the credentials of the connecting user:

$ strace dbus-daemon --session --nofork
...
accept4(4, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 8
...
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0

So to answer your questions:

The D-Bus daemon is using your kernel-verified user ID to verify your identity. By using socat to proxy connections, you are letting anybody connect to the D-Bus daemon using your UID.
If you try to connect directly to the socket from another UID, the daemon recognizes that the connecting UID is not a UID that is supposed to be allowed to connect. I believe the default is that only the daemon's own UID is allowed, but haven't formally verified that. You can allow other users, though: see the configuration files in /etc/dbus-1/, and also man dbus-daemon.
This is the D-Bus server replacing old/expired cookies with new ones. According to the DBUS_COOKIE_SHA1 section of the D-Bus spec, a cookie is stored along with its creation time, and the server is supposed to delete cookies that it decides are too old. Apparently the lifetime "can be fairly short".

Centos – Mount CIFS shares as non-root on RHEL7 w/o desktop

Instead of using gvfs-mount, which is really intended for working within a graphical login, I've successfully done this using autofs.

I just have an autofs config file in /etc/auto.master.d/ called winhome.autofs (it has to end with .autofs), and it looks something like this:

/winhome -fstype=cifs,sec=krb5,uid=&,user=&,cruid=& ://sharename/&

As long as you have sssd set up to get you a kerberos ticket, it will use that ticket to automatically mount the volume \sharename\username when the user opens that directory (either using a graphical app or through the shell).

Best Answer

Related Solutions

D-Bus Security – Understanding D-Bus Authentication and Authorization

Centos – Mount CIFS shares as non-root on RHEL7 w/o desktop

Related Question