dbus-server-socket: Make unix:tmpdir equivalent to unix:dir
authorSimon McVittie <smcv@collabora.com>
Thu, 29 Sep 2022 15:50:07 +0000 (16:50 +0100)
committerSimon McVittie <smcv@collabora.com>
Sun, 2 Oct 2022 14:05:35 +0000 (15:05 +0100)
On Linux, there are two classes of AF_UNIX socket, which D-Bus refers
to as unix:path=... (portable to non-Linux systems) and unix:abstract=...
(not portable).

Back in 2003 when dbus gained support for abstract Unix sockets on Linux,
everyone thought they were better in every way than path-based Unix
sockets: if a DBusServer crashes or is terminated abnormally, there's
no detritus left in the filesystem. What's not to like? As a result,
since commit a70b042f (2003-06-04), when a DBusServer listens on a
unix:tmpdir=... address on Linux, the default is for the result to be
a unix:abstract=... address, with unix:path=... addresses only used on
non-Linux platforms.

However, the world has changed in the last 19 years, and namespace-based
Linux containers (which didn't exist in 2003) are now very popular. This
makes abstract sockets problematic.

Abstract sockets are tied to the network namespace, which is
all-or-nothing: if a container is to access the Internet without using
some sort of proxy or intermediary (like slirp4netns) then it needs to
share the network namespace with the host system, and that implies
sharing all abstract sockets with the host system. If the well-known
session bus is listening on an abstract socket, then it's a sandbox
escape route for any sandboxed or containerized app running under the
same uid. Conversely, if a container is *not* sharing the network
namespace with the host system, then it cannot access a session bus that
is listening on an abstract socket without using some sort of proxy
(like xdg-dbus-proxy), even if it isn't intended to impose a security
boundary and giving it direct access to the session bus would have been
more desirable.

Path-based sockets do not have this problem because they exist in the
filesystem (part of the "everything is a file" Unix philosophy),
allowing mount namespaces and bind-mounts to be used to share or
unshare them selectively.

On systems with `systemd --user` where dbus has been configured with
`--enable-user-session`, in general the session bus will already be
using a path-based socket for the "user bus", disregarding the listening
address specified in /usr/share/dbus-1/session.conf. The default in many
recent Linux distributions is either to use dbus-daemon in this way, or
to use dbus-broker, a reimplementation of the message bus service which
has similar "user bus" behaviour.

However, the <listen> address in session.conf is used when dbus-launch(1)
or dbus-run-session(1) is used to start a session bus, either manually,
via autolaunching, or via system integration glue in operating systems
that are not using `systemd --user`. This will occur particularly often
in operating systems that boot using a non-systemd init system.

Making unix:tmpdir=/tmp equivalent to unix:dir=/tmp ensures that the
well-known session bus listens on a path-based socket, allowing container
and sandboxing frameworks to mediate access to it in the same way they
would for the user bus. The D-Bus Specification already allows (but does
not require) this behaviour, because it is the only thing that was
implementable on non-Linux systems such as *BSD.

This change has the potential to cause regressions. If a container
framework enters a chroot or unshares the mount namespace but does not
unshare the network namespace, and is relying on the ability for a
process inside a container to access the session bus outside the
container via its abstract socket, then that assumption will be broken
by this change. Some use cases of schroot(1) are likely to suffer from
this. However, container frameworks with that assumption would already
have found that it does not hold when using the user bus, and it is
necessary to break that assumption if we want it to be possible to apply
application-level sandboxing in a secure way.

Another potential regression from this change is that if a dbus-daemon
is terminated abnormally, it will leave a socket in /tmp. Distributors
of operating systems where heavy use of dbus-launch(1) is expected might
wish to run dbus-cleanup-sockets(1) periodically.

This partially reverts commit a70b042f.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/416
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f01382ae310c7d63790c07ed280f575d91ea57b8)
[backport to 1.14.x: adjust to absence of d98c98d1 in this branch]
(cherry picked from commit b5a09fb11c05b3b1922e99d18720f586fc91cd0b)

dbus/dbus-server-unix.c

index c7ace2b..87cb53a 100644 (file)
@@ -139,19 +139,11 @@ _dbus_server_listen_platform_specific (DBusAddressEntry *entry,
         {
           DBusString full_path;
           DBusString filename;
-          dbus_bool_t use_abstract = FALSE;
 
+          /* tmpdir is now equivalent to dir. Previously it would try to
+           * use an abstract socket. */
           if (tmpdir != NULL)
-            {
-              dir = tmpdir;
-
-#ifdef __linux__
-              /* Use abstract sockets for tmpdir if supported, so that it
-               * never needs to be cleaned up. Use dir instead if you want a
-               * path-based socket. */
-              use_abstract = TRUE;
-#endif
-            }
+            dir = tmpdir;
 
           if (!_dbus_string_init (&full_path))
             {
@@ -192,7 +184,7 @@ _dbus_server_listen_platform_specific (DBusAddressEntry *entry,
 
           *server_p =
             _dbus_server_new_for_domain_socket (_dbus_string_get_const_data (&full_path),
-                                                use_abstract,
+                                                FALSE,
                                                 error);
 
           _dbus_string_free (&full_path);