We cannot safely log between fork() and exec() because it isn't an
async-signal-safe operation (in particular it might allocate memory).
We also don't want to treat a failure here as a real problem, because
it might legitimately not work: in a system dbus-daemon that has dropped
privileges from root, the pseudo-file representing this process parameter
remains owned by root and cannot be altered by the unprivileged user.
For the main use-case for this operation, the system dbus-daemon, we
have another opportunity to do this in the dbus-daemon-launch-helper
(see the previous commit).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7ee72a2795)
Previously, we were relying on the system bus being able to reset
its OOM score adjustment after it forks, but before it execs the
dbus-daemon-launch-helper. However, it can't actually do that (leading
to dbus#378), because the system bus typically starts as root, uses its
root privileges to adjust resource limits, and then drops privileges
to the `@DBUS_USER@`, typically `dbus` or `messagebus`. This leaves the
pseudo-files in /proc for its process parameters owned by root, and the
`@DBUS_USER@` is not allowed to open them for writing.
The dbus-daemon-launch-helper is setuid root, so it can certainly
alter its OOM score adjustment before exec'ing the actual activated
service. We need to do this before dropping privileges, because after
dropping privileges we would be unable to write to this process
parameter.
This is a non-async-signal-safe context, so we can safely log errors
here, unlike the fork-and-exec code paths.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/378
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2efb462466)
The oom_score_adj parameter is a signed integer, with increasingly
positive values being more likely to be killed by the OOM-killer,
and increasingly negative values being less likely.
Previously, we assumed that oom_score_adj would be negative or zero,
and reset it to zero, which does not require privileges because it
meant we're voluntarily giving up our OOM-killer protection.
In particular, bus/dbus.service.in has OOMScoreAdjust=-900, which
we don't want system services to inherit.
However, systemd >= 250 has started putting a positive oom_score_adj
on user processes, to make it more likely that the OOM killer will kill
a user process rather than a system process. Changing from a positive
oom_score_adj to zero is increasing protection from the OOM-killer,
which only a privileged process is allowed to do, resulting in warnings
whenever we carry out traditional (non-systemd) service activation
on the session bus.
To avoid this, do the equivalent of:
if (oom_score_adj < 0)
oom_score_adj = 0;
which is always allowed.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/374
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c42bb64457)
The session dbus-daemon won't necessarily be run immediately on login
if we are using systemd socket activation for it, and the transient
services directory $XDG_RUNTIME_DIR/dbus-1/services isn't created until
it's actually run. Ping the dbus-daemon to make sure it's available.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1005889
(cherry picked from commit 47a4bdfaf8)
Debian 9 'stretch' is EOL, and Ubuntu 16.04 is EOL unless you enter into
a special subscription with Canonical. This puts them outside our
informal security-support policy, and realistically, anyone sufficiently
change-averse to be following these distributions is not going to be
backporting a current version of dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 69c610f6f0)
The length if the displayed jobs is limited on the gitlab CI pipeline page
and is occupied partly be the prefix.
Cherry-picked from dbus/dbus/!192
(cherry picked from commit d2bab84329)
Debian 8 'jessie' has reached EOL for mainstream security support,
which puts it outside our usual distribution/OS support policy.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3ce28815e9)
Previously, we built on Debian 9 'stretch' by default, and on
Debian 10 'buster' only on request. Let's reverse that so that we get
more modern toolchains, before Debian 9 'stretch' reaches EOL.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 73cfcb95c6)
The dbus-1.12 branch needed Python, which the master branch no longer
does, but we can at least use a modern Python.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In dbus 1.12.x, this was a tar.gz archive, not a tar.xz archive.
Fixes: 8d34987e "CI: Exercise maintainer-only documentation build"
Signed-off-by: Simon McVittie <smcv@collabora.com>
With this commit a new variable 'ci_local_packages' has been introduced
to have a choice for using development packages from a local installation
or from the distribution.
(cherry picked from commit 9c5734fe90)
This required a reorganization of the steps that had been carried out.
The new order is:
1. install packages with apt-get
2. create user for build if required
3. fetch and unpack tar balls
4. create messagebus user
(cherry picked from commit 478484f13c)
[backport for 1.12.x: This branch still needed python-dbus, python-gi]
Signed-off-by: Simon McVittie <smcv@collabora.com>
We officially release dbus in the form of Autotools `make dist` tarballs,
but people who have downloaded those tarballs should be able to choose
the CMake build system. Our CI should assert that they can.
(The Autotools debug build already does a `make distcheck`, which
asserts that tarball releases can be used for an Autotools build.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#255
(cherry picked from commit 1063bba06b)
[backport for 1.12.x: in 1.12.x, `make dist` produces .tar.gz]
In particular this avoids installing the TeX toolchain.
However, this also means we don't install dbus, which broke some tests
in minimal containers where dbus wasn't already installed, because the
messagebus user wouldn't have been created. Make sure that user exists,
using the same adduser call as the Debian dbus package.
CMake really wants to find a C++ compiler (even though we only use C++
when compiling for Windows), so explicitly install the default
version of the GNU C++ compiler, g++.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit cb6abc6391)
The older versions we were previously building against are no longer
available on mirrors.
Based on changes proposed in !189 by Arnout Engelen, and the package
list gathered by Ralf Habacker in #318.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/318
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 053238254e)
Originally part of commit 23e1f044 "Install qhelpgenerator for native
production build on buster". Later CI fixes rely on having this
available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
clang 13 fails to compile our current implementation with:
.../dbus/dbus-message.c:2070:3: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
_DBUS_STATIC_ASSERT (_DBUS_ALIGNOF (DBusMessageRealIter) <=
^
.../dbus/dbus-internals.h:460:25: note: expanded from macro '_DBUS_STATIC_ASSERT'
typedef struct { char _assertion[(expr) ? 1 : -1]; } \
This appears to be because the "traditional" definition of
offsetof(), which we're hard-coding here, does not qualify as a constant
expression under C rules due to its use of pointer casts.
Modern compilers like gcc and clang have a built-in implementation
of offsetof that *is* a constant expression.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a24cf746e2)
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).
(cherry picked from commit 3fab06d68f)
This is sorted non-deterministically, which is undesired for reproducible
builds, and is not really part of the API in any case.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ce8d7759a2)
With this parameter, docbook will generate the same id's when generating the
same docs. This is helpful to get bit-by-bit 'reproducible' output, which
makes auditing the package easier.
(cherry picked from commit 43e0188dbf)
dbus-daemon fails to autolaunch with X11 on macOS 10.8+ because XQuartz
(the X11 package for macOS) provides a value for `$DISPLAY` that is
not expected by dbus, in that it contains `/` characters. This is
addressed by replacing the invalid path character `/` with `_`.
Resolves: #8Resolves: #311
(cherry picked from commit 3545d0f4de)
dbus-daemon fails to launch on macOS 10.5 and above because of a breaking
change in setrlimit, in which RLIM_INFINITY is no longer supported
for RLIMIT_NOFILE. Instead we must use OPEN_MAX.
Resolves: #309
(cherry picked from commit 691946dabc)
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>
(cherry picked from commit f0e526bca8)
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: dbus#305
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2b7948ef90)
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>
(cherry picked from commit 6ee66ff7bc)
This version is for the dbus-1.12 branch, and doesn't rely on dbus!153
or dbus!120.
Reproduces: dbus#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: dbus#294
Fixes: CVE-2020-12049
Fixes: GHSL-2020-057
