Simon McVittie [Fri, 25 Feb 2022 16:08:32 +0000 (16:08 +0000)]
CI: Use current Debian stable release for mingw-w64 builds
Now that we have resolved the failure to build with newer mingw-w64,
we don't need to hold these back to Debian 10 'buster' and can upgrade
to the current stable release, Debian 11 'bullseye'.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 25 Feb 2022 16:06:59 +0000 (16:06 +0000)]
build: Opt out from using mingw-w64's replacement printf(), etc.
The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't need to substitute a Standard C printf implementation.
This avoids compiler warnings/errors when gcc expects us to be using
Microsoft printf syntax (`ms_printf` attribute), but newer versions of
mingw-w64 expect us to be using GNU or Standard C printf syntax
(`gnu_printf` attribute) as a result of `__USE_MINGW_ANSI_STDIO` being
enabled by default if not otherwise specified.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/380 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 25 Feb 2022 13:48:05 +0000 (13:48 +0000)]
CI: Build on Debian 11 'bullseye' instead of Debian 10 'buster'
This is the current stable release for Debian, making Debian 10 a much
less interesting target for backports. Add a manually-triggered job
so we can still try buster occasionally.
Continue to use buster for mingw-w64 builds until format string issues
with bullseye toolchains can be sorted out.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 25 Feb 2022 13:45:10 +0000 (13:45 +0000)]
CI: Remove EOL versions of Debian and Ubuntu
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>
Simon McVittie [Fri, 25 Feb 2022 13:53:56 +0000 (13:53 +0000)]
Disable MSVC CI by default for now
The necessary CI runner doesn't seem to be available, and we shouldn't
let that prevent us from merging dbus changes. This can be reverted
when the runner comes back.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 21 Feb 2022 16:07:26 +0000 (16:07 +0000)]
sysdeps-unix: Diagnose failure to open /proc/self/oom_score_adj
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>
Simon McVittie [Mon, 21 Feb 2022 16:02:13 +0000 (16:02 +0000)]
spawn-unix: Don't log an error if unable to reset Linux OOM score
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>
Simon McVittie [Mon, 21 Feb 2022 16:00:42 +0000 (16:00 +0000)]
dbus-daemon-launch-helper: Reset Linux OOM score adjustment here
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>
Simon McVittie [Mon, 21 Feb 2022 15:53:38 +0000 (15:53 +0000)]
spawn-unix: On Linux, don't try to increase OOM-killer protection
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>
Simon McVittie [Mon, 21 Feb 2022 10:35:10 +0000 (10:35 +0000)]
tests: Ensure session bus has started before integration test
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
Jan Tojnar [Thu, 11 Feb 2021 05:00:45 +0000 (06:00 +0100)]
doc: Introduce XML catalog
This adds a nice way of loading the DTD files based on the identifier
in the DOCTYPE declaration, no matter where the DTDs are installed.
See also ‘XML catalog’ Wikipedia entry and update-xmlcatalog(8).
Ralf Habacker [Tue, 15 Feb 2022 23:14:37 +0000 (00:14 +0100)]
dbus-daemon: Implement signal 'ActivatableServicesChanged'
After any reload of the activatable service files the mentioned signal is
emitted to the current bus to inform clients.
The calls to signal emmission have not been implemented in the platform
specific functions _dbus_daemon_report_reloaded() to avoid duplicate
implementations.
Kir Kolyshkin [Tue, 1 Feb 2022 04:31:11 +0000 (20:31 -0800)]
spec: add * to optionally-escaped bytes set
Commit ee71e1ff6033a added * to the list of optionally escaped bytes
set, but did not update the documentation. I guess this happened because
the change is not backward compatible.
It seems that the period of 14+ years should be enough to not cause any
backward compatibility issues, so let's document this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Ralf Habacker [Tue, 14 Dec 2021 14:32:56 +0000 (15:32 +0100)]
_dbus_get_address_string() now expects an initialized DBusString instance as a parameter
The mentioned function now expects an initialized DBusString instance as
parameter for the return of a string to have a clear responsibility
regarding initialization and usage and thus simplify the "out of memory"
management.
Since the _dbus_get_shm_name() and _dbus_get_mutex_name() functions are
affected by the change, the related documentation has been adapted.
Simon McVittie [Wed, 15 Dec 2021 12:31:54 +0000 (12:31 +0000)]
test: Avoid misleading diagnostic when some tests are skipped
If we have 7 test-cases, of which we ran 3 and skipped 4, then it's
misleading to say "7 tests passed". Diagnose this as
"3 tests passed (4 skipped)" instead.
We can either skip tests by putting a specific test name on the test
command-line, or programmatically (for example the fd-passing test is
always skipped on Windows, because Windows cannot implement Unix
fd-passing).
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/363 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Wed, 15 Dec 2021 11:41:05 +0000 (11:41 +0000)]
sysdeps: Make some functions Windows-specific
_dbus_daemon_publish_session_bus_address had an empty implementation
but was never actually called on Unix, and
_dbus_daemon_is_session_bus_address_published wasn't even implemented.
Move them to the Windows-specific header to indicate that interface
changes here would only affect other Windows-specific code.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 10 Dec 2021 15:12:59 +0000 (15:12 +0000)]
internals: Use Standard C offsetof macro if available
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>
projects / thirdparty / dbus.git / log
