Without this running, dbus-daemon with long XDG_DATA_DIRS
will crash on out-of-bounds write:
$ XDG_DATA_DIRS=$(seq -f "/foo/%g" -s ':' 129) dbus-daemon --session
*** stack smashing detected ***: terminated
(cherry picked from commit b551b3e973)
Backported-from: dbus!302
(cherry picked from commit 9e8fe0718c)
dbus 1.12.x was included in both Debian 10 'buster', which is now EOL,
and Debian 11 'bullseye', which continues to be supported. I need this
branch to work on Debian 11 for security and bugfix backports, but I'm
no longer supporting Debian 10.
Leave one build variant, the "legacy" build, on Debian 10 to check that
we can still build there, to be nice to the Debian LTS subproject.
Also continue to use Debian 10 for mingw builds, since dbus#380 has
not been fixed in this branch (which is now the security-fix-only
old-stable branch, so the fix will not be backported).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Similar to dbus/dbus!286, but more so: just use the package names,
ignoring their version numbers completely.
pcre2 is not strictly needed at the moment, but it'll be a dependency
for GLib >= 2.73.x (older versions used pcre). For a bit of
future-proofing, download both pcre and pcre2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8aa34131dd)
This is necessary to have a clean initial state when running the script
locally.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit 067733d4b0)
Instead of having to specify an exact version that needs to be adjusted
with each repository update, it is now possible to specify package names
without version or partially qualified versions, which reduces the
frequency of necessary adjustments.
This is achieved by searching for the package names in a previously
downloaded list of available packages.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit 7e9d3708b1)
Previously, we silently ignored this, but now that we're more careful
about the contexts in which we try to reset the OOM score and whether
we log failures as a warning, we can let the dbus-daemon-launch-helper
show a message if it can't write there.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 226f24144a)
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)
