GitLab

doc: Fix typo in dbus-daemon(1)

See merge request !183

disable fork-malloc-exec for non-glibc-systems

See merge request !181

Calling malloc() after fork is undefined behaviour if the process is
multi-threaded. locks held by a thread on fork() will never be released.
malloc() is usally protected by a lock and can therefore deadlock. glibc
is known not to deadlock in this case.

This commit does not rule out other problems on glibc-systems, but fixes an
issue on musl-libc-systems. Only restricting to async-signal safe functions
between fork() and exec() prevents undefined behaviour for sure. See
signal-safety(7).

CMake: allow traditional activation to be disabled

See merge request !159

Traditional activation is enabled/disabled with the cmake configure
parameter -DENABLE_TRADITIONAL_ACTIVATION, which is enabled by default.

This was added to the Autotools build system as part of !107
but until now was not possible to disable when building with CMake.

cmake: move up checking DBUS_ENABLE_EMBEDDED_TESTS from subdir test/name-test to test

See merge request !177

The whole file is only added with the mentioned variable
set, so it can also be skipped completly one level up.

cmake: install dbus-daemon-launch-helper

Closes #310

See merge request !175

Previously it was built on Unix platforms, but not installed. This
would prevent traditional activation on the system bus (on Linux
without systemd or non-Linux, or for services without SystemdService),
which requires the activation helper.

Because the executable is an internal implementation detail of how
traditional activation is implemented on Unix, it is not exported to
the generated cmake support files.

Resolves: #310

spec: Update recommendations for DBUS_COOKIE_SHA1 timeouts

See merge request !171

This had two issues that could damage interoperability.

First, the spec wording suggested that any cookie that had not been
deleted was suitable for use in authentication. However, this introduces
a race condition, which is called out in comments in both the reference
implementation and GDBus: the newest cookie might be less old than the
arbitrary lifetime when authentication *begins*, but older than the
lifetime at the time authentication *ends*. As a result, we need a grace
period during which an old cookie will still be accepted, but a newer
cookie exists and will be used for new authentication operations.

Second, the spec wording implied that the arbitrary timeouts were
completely up to the implementor. However, GLib bug
https://gitlab.gnome.org/GNOME/glib/-/issues/2164 indicates that they
need to be reasonably compatible: in particular, GDBus servers
historically didn't allocate new cookies until 10 minutes had passed,
but libdbus clients would decline to use a cookie older than 5 minutes,
causing authentication to fail if the gdbus-server test-case (in which
GDBus and libdbus clients connect to a GDBus server) happened to take
longer than 5 minutes to run.

While I'm here, also be consistent about calling the secrets "cookies"
(consistent with the name of the mechanism) rather than "keys" (which
is what they are called in libdbus' dbus-keyring.c).
Signed-off-by: Simon McVittie <smcv@collabora.com>

tests: On Unix, include <netinet/in.h> for IPPROTO_TCP

See merge request !167

Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
are enabled (which suggests that no FreeBSD user has run those tests
successfully).

We already include <netinet/in.h> in other places with no conditions
or checks other than "is Unix", so apparently it's portable enough that
specifically testing for its presence is not necessary. POSIX requires it
to exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

userdb: Reference-count DBusUserInfo, DBusGroupInfo

Closes #305

See merge request !166

Previously, the hash table indexed by uid (or gid) took ownership of the
single reference to the heap-allocated struct, and the hash table
indexed by username (or group name) had a borrowed pointer to the same
struct that exists in the other hash table.

However, this can break down if you have two or more distinct usernames
that share a numeric identifier. This is generally a bad idea, because
the user-space model in such situations does not match the kernel-space
reality, and in particular there is no effective kernel-level security
boundary between such users, but it is sometimes done anyway.

In this case, when the second username is looked up in the userdb, it
overwrites (replaces) the entry in the hash table that is indexed by
uid, freeing the DBusUserInfo. This results in both the key and the
value in the hash table that is indexed by username becoming dangling
pointers (use-after-free), leading to undefined behaviour, which is
certainly not what we want to see when doing access control.

An equivalent situation can occur with groups, in the rare case where
a numeric group ID has two names (although I have not heard of this
being done in practice).

Solve this by reference-counting the data structure. There are up to
three references in practice: one held temporarily while the lookup
function is populating and storing it, one held by the hash table that
is indexed by uid, and one held by the hash table that is indexed by
name.

Closes: #305Signed-off-by: Simon McVittie <smcv@collabora.com>

This makes it more obvious that the returned pointer points to a
struct owned by the userdb, which must not be freed or have its
contents modified, and is only valid to dereference until the next
modification to the userdb's underlying hash tables (which in practice
means until the lock is released, because after that we have no
guarantees about what might be going on in another thread).
Signed-off-by: Simon McVittie <smcv@collabora.com>

Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNC

Closes #304

See merge request !165

cmake: Fix installed files

See merge request !155

Systemd user support is controlled by the cmake variable ENABLE_USER_SESSION,
which and WITH_SYSTEMD_USERUNITDIR to specify a custom installation
location. If WITH_SYSTEMD_USERUNITDIR is not specified, the related install
path is determined from an installed systemd package, if present.

This was added to the Autotools build system as part of fd.o#61301,
but until now was not possible to enable when building with CMake.

Previously, only the Autotools build system could do this. This commit
includes most of the same features as in the Autotools build, although
not the user-session semantics, which will be added separately.

Systemd support is controlled by the cmake variable ENABLE_SYSTEMD, which can
have the values OFF, ON and AUTO, the latter enabling support by default if
the required libraries are available.

With WITH_SYSTEMD_SYSTEMUNITDIR a custom installation location can be specified.
If it is not specified, the related install path is determined from the installed
systemd package, if present.

check_auto_option() checks the values given to an auto-option and prints
a fatal error in case of invalid combinations.

This means we apply GNUInstallDirs' various special cases when
the prefix is /, /usr or something starting with /opt; these are
not applied when installing to CMAKE_INSTALL_<dir>. See
https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#special-cases

Normalize C source files to end with exactly one newline

See merge request !162

Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to dbus,
let's pre-emptively normalize all files.

Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.

Implemented by:

    find . -name '*.[ch]' -print0 | \
    xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>

dbus-protocol.h: fix DBUS_ERROR_SPAWN_NO_MEMORY comment

See merge request !163

Although this error seems to be unused (DBUS_ERROR_NO_MEMORY is used
instead), let's correct the comment.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Reproduces: #294
Reproduces: CVE-2020-12049
Reproduces: GHSL-2020-057
Signed-off-by: Simon McVittie <smcv@collabora.com>

MSG_CTRUNC indicates that we have received fewer fds that we should
have done because the buffer was too small, but we were treating it
as though it indicated that we received *no* fds. If we received any,
we still have to make sure we close them, otherwise they will be leaked.

On the system bus, if an attacker can induce us to leak fds in this
way, that's a local denial of service via resource exhaustion.

Reported-by: Kevin Backhouse, GitHub Security Lab
Fixes: #294
Fixes: CVE-2020-12049
Fixes: GHSL-2020-057

Signed-off-by: Simon McVittie <smcv@collabora.com>

CI: run cross compiled tests

Closes #296

See merge request !158

This helps to detect incorrect settings.

Before building a wine prefix is created and search pathes
for binaries are configured in the wine prefix.

This commit adds a new shell variable 'ci_runtime' for specifing
the type of compiler support library which defaults to static for now.