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>
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>
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>
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
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).
A prefix has been added to the custom target names in docbook-related
macros to fix the reported error:
ninja: error: build.ninja:xxx: multiple rules generate
doc/dbus-xxx.1.html [-w dupbuild=err]
Fixes#377
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
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.
Fixes#376
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Commit ee71e1ff60 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>
Based on GStreamer & Mesa freedesktop gitlab CI, use the Windows 1809
runner provided by the GStreamer Foundation.
https://www.freedesktop.org/wiki/Infrastructure/
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As we are introducing Windows builds next, move out Unix-specific
job definitions to the base job.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
It is easier to read and modify than anchors. And we are going to move
more Debian-specific to the base ".debian-build" next.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Jumping to "out" will call _dbus_string_zero() unconditionally on tmp
string variables. Do not attempt to zero what wasn't even initialized.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This cleanup has been processed in _dbus_daemon_publish_session_bus_address()
_dbus_get_install_root_as_hash() and _dbus_get_address_string().
The zero length condition has been catched in each function calling
the mentioned functions.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Since the _dbus_get_address_string() function is affected by the change,
the code calling the mentioned function been adapted.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
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.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
The corrections refer to the following commits, so that they are not mixed
up with blank changes.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
