Simon McVittie [Fri, 18 Aug 2023 16:15:32 +0000 (17:15 +0100)]
bus: Don't crash if inotify fails, even under DBUS_FATAL_WARNINGS=1
When running tests, we use DBUS_FATAL_WARNINGS=1 to make the tests fail
on internal errors. Failing to set up inotify is not really an internal
error: it's more like an environmental error, which can occur for
reasons outside our control.
Instead, log using bus_context_log(), which never crashes the process
and always just logs a warning.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/473
Simon McVittie [Thu, 29 Jun 2023 18:52:39 +0000 (19:52 +0100)]
bus: When failing to reload client policy, continue iteration
If we have a large number of connections to the bus, and we fail to
reload the policy for one of them (perhaps because its uid no longer
exists in the system user database), previously we would crash, which
is obviously unintended. After the previous commit, we would stop
iteration through the list of client connections, which doesn't seem
great either: one bad connection shouldn't prevent us from reloading
the rest of our state.
Instead, let's distinguish between new connections (where we want
failure to establish a security policy to be fatal), and pre-existing
connections (where the current security policy is presumably good
enough to keep using if we have nothing better). If we're unable to
reload the policy for a pre-existing connection, log a warning and
carry on iterating.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Thu, 29 Jun 2023 15:06:39 +0000 (16:06 +0100)]
userdb: Add proper error reporting when getting groups from a uid
Previously, if dbus_connection_get_unix_user() succeeded but
_dbus_unix_groups_from_uid() failed, then bus_connection_get_unix_groups()
would incorrectly fail without setting the error indicator, resulting
in "(null)" being logged, which is rather unhelpful.
This also lets us distinguish between ENOMEM and other errors, such as
the uid not existing in the system's user database.
Peter Benie [Fri, 23 Jun 2023 10:51:00 +0000 (11:51 +0100)]
bus: Don't crash if bus_context_create_client_policy() fails
If policy creation fails, we can't usefully leave a NULL policy in the
BusConnectionData. If we did, the next attempt to reload policy would
crash with a NULL dereference when we tried to unref it, or with
an assertion failure.
One situation in which we can legitimately fail to create a client policy
is an out-of-memory condition. Another is if we are unable to look up a
connection's supplementary groups with SO_PEERGROUPS, and also unable to
look up the connection's uid's groups in the system user database, for
example because it belongs to a user account that has been deleted (which
is sysadmin error, but can happen, particularly in automated test systems)
or because a service required by a Name Service Switch plugin has failed.
Keeping the last known policy is consistent with what happens to all
the connections that are after this one in iteration order: after we
early-return, all of those connections retain their previous policies
(which doesn't seem ideal either, but that's how this has always worked).
[smcv: Add commit message] Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343
Simon McVittie [Tue, 15 Aug 2023 14:37:37 +0000 (15:37 +0100)]
Add REUSE copyright/license information for binary message blobs
Most of these binary blobs is mechanically derived from the
corresponding .hex file, which is hand-written.
boolean-has-no-value.message-raw is presumably either hand-constructed
or fuzzer-generated: it was committed by a Red Hat employee and never
altered, so I've assumed Red Hat is the copyright holder. Permission
was already granted by Red Hat to relicense their dbus contributions
under the MIT (Expat) license.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 14 Aug 2023 18:53:11 +0000 (19:53 +0100)]
sysdeps: Use C11 stdatomic.h where possible
On Unix, dbus has historically used gcc-specific lock-free atomic
intrinsics where available, falling back to a pthreads mutex where
possible. Meanwhile, on Windows, it has historically used
InterlockedIncrement() and similar library functions (in practice
wrappers around lock-free intrinsics on real Windows, but IPC calls into
wineserver on Wine).
ISO C11 provides a new header, stdatomic.h, with standardized support
for atomic operations. Exactly how these are implemented is a compiler
quality-of-implementation decision, but any reasonable compiler
implementation on a modern CPU should be using intrinsics. Let's use
this wherever possible, falling back to our old implementation only if
the C11 implementation is unsupported.
One concrete benefit that we get from this is that when compiling with
mingw-w64 gcc and running via Wine, this makes atomic reference counting
operations into a simple local operation, rather than IPC to wineserver
which can be very slow. This should make our CI tests considerably more
reliable.
In all vaguely modern gcc versions (gcc 5.5 or later) and in contemporary
versions of clang, the default compiler mode is C11 or later with GNU
extensions. We intentionally do not ask for any specific C standard, so
we can use C11 features like this one, as long as we do so conditionally.
The Microsoft Visual C compiler does not currently support this without
special options, so we still use the Interlocked family of functions
when compiling for Windows with MSVC.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Tue, 15 Aug 2023 11:50:19 +0000 (12:50 +0100)]
sysdeps: Move declarations used from C++ to their own header
I want to use <stdatomic.h> in dbus-sysdeps.h, but if we do that, we
won't be able to include that header into C++ code on all compilers.
Move the declarations for new internal Windows-specific functions
introduced in commit 17a23d08
"dbus_threads_init_default, dbus_threads_init: be safe to call at any time"
into their own header.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Tue, 8 Aug 2023 11:02:51 +0000 (12:02 +0100)]
meson: Allow `sudo meson install`, which doesn't set `DESTDIR`
This is generally not recommended (dbus should usually be installed from
the OS distributor's packages, which should install into a staging
directory using `DESTDIR`), but we'll want to use it in Gitlab-CI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Tue, 15 Aug 2023 12:06:18 +0000 (13:06 +0100)]
Continue to recommend CMake when building on Windows
In the longer term I'd like to move everything towards Meson so we only
have one primary build system, but at the moment Ralf would prefer to
keep recommending CMake for Windows builds (see dbus!378) so let's
stick with that for now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ralf Habacker [Tue, 8 Aug 2023 17:39:49 +0000 (19:39 +0200)]
Use Meson for the 'reduced' and 'legacy' build variants
There are some differences between Autotools and Meson here:
- Because we detect native atomic operations differently, we can no
longer emulate a platform that doesn't have them, such as ARMv4;
but modern OSs no longer support ARMv4 and all significant hardware
platforms now have native atomic operations, so this is now less of
a concern.
- Similarly, we can no longer emulate a platform that doesn't have the
getrandom() library function, but that function is available in all
relevant glibc versions (such as CentOS >= 8, Debian >= 10,
Ubuntu >= 18.04) so testing the fallback path is less of a concern now.
We also no longer try to disable dnotify in the legacy build, but our
dnotify code path was removed in 2013, so --disable-dnotify didn't do
anything anyway.
[Separated from a larger commit on dbus!378 —smcv]
Co-authored-by: Simon McVittie <smcv@collabora.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we are recommending Meson, let's de-emphasize Autotools.
Anyone who still needs Autotools will already know how it works, at
least generically.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 7 Aug 2023 19:19:17 +0000 (20:19 +0100)]
On 32-bit glibc, define _TIME_BITS to 64 if not already defined
On older 32-bit architectures such as i386, this redefines time_t to be
64-bit, and correspondingly increases the size of all system data
structures that contain a time_t, such as struct timeval and struct stat.
This is necessary to allow timestamps beyond January 2038 to be
represented; as well as things that obviously deal with timestamps,
this affects functions like stat() (and therefore our wrapper
_dbus_stat()), which will fail with EOVERFLOW if asked to inspect a
file whose correct timestamp does not fit in time_t.
In particular, if the modification or access timestamp on
/etc/machine-id has somehow been set to a post-2038 time, libdbus will
consider the inability to stat() that file to be an installation error,
and when using the deprecated dbus_get_local_machine_id(), that can
cause third-party i386 software such as the Steam client to crash.
Using 64-bit timestamps avoids that failure mode.
Using 64-bit timestamps in glibc is an opt-in and not the default,
because if done carelessly it can change libraries' ABIs. However,
libdbus is careful not to include system headers and system data
types in its own headers, with the only exceptions being extremely
basic ISO C headers like <stddef.h> and <stdarg.h>; so we can safely
do this without it breaking our ABI. This is similar to the reasoning
for why commit 96ffc2a0 "configure.ac: support large-file for stat64"
was a safe change.
This change only affects glibc. Some non-GNU operating system libraries
(such as musl) are less concerned with binary backwards compatibility
than glibc, and therefore have incompatibly changed their ABI on 32-bit
platforms to switch to 64-bit timestamps throughout; no action is needed
on those platforms. If other non-GNU OS libraries have taken a route
similar to GNU's, then maintainers of those operating systems are
welcome to send tested merge requests similar to this one.
An extra subtlety here is that _TIME_BITS=64 requires
_FILE_OFFSET_BITS=64. In the Meson build, Meson unconditionally enables
_FILE_OFFSET_BITS=64 where appropriate, and in the Autotools build,
we already had that via AC_SYS_LARGEFILE, but in the CMake build we
did not necessarily have this; so we also define _FILE_OFFSET_BITS=64
there if necessary, as a continuation of commit 96ffc2a0
"configure.ac: support large-file for stat64".
On newer 32-bit architectures like x32, time_t is always 64-bit and so
this has no practical effect.
On 64-bit, setting these would have no practical effect, but to minimize
risk I'm only doing this for 32-bit architectures.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/465 Signed-off-by: Simon McVittie <smcv@collabora.com>
Luca Boccassi [Mon, 20 Mar 2023 02:00:51 +0000 (02:00 +0000)]
DBusCredentials: add support for PID FDs via SO_PEERPIDFD
The new socket option SO_PEERPIDFD allows to pin the process on the
other side of the socket by file descriptor, which closes a race
condition where a PID can be reused before we can pin it manually.
Available since Linux v6.5.
When storing credentials, pin the process by FD from the PID.
When querying the PID, if the PID FD is available, resolve
it from there first if possible.
Ensure the DBusCredentials object only returns the PID FD if it was
obtained by this call, so that we know for sure we can rely on it
being safe against PID reuse attacks.
Ralf Habacker [Mon, 7 Aug 2023 09:36:21 +0000 (11:36 +0200)]
tools/ci-build.sh: cleanup setup and usage of ci_builddir
The order and arrangement of the initialization of the build directories
has been improved: the deletion of special directories have been moved to
the associated part, the rest have been merged and there is a default
value if not specified as an environment variable, making it easier to
execute on the command line.
Ralf Habacker [Fri, 4 Aug 2023 09:56:12 +0000 (11:56 +0200)]
CI: add prefix 'ci_' to env var 'builddir'
This customization simplifies their use, e.g. when outputting the command
line used. Because of FreeBSD, 'awk' is used instead of 'gawk' to make
sure that the tool is available.
Luca Boccassi [Mon, 20 Mar 2023 01:48:06 +0000 (01:48 +0000)]
systemd: start as the D-Bus user/group, rather than root
When starting as root files in /proc/self/fdinfo/ will be owned as root
and set to 400, so we cannot read them. Nowadays it is not necessary to
start as root when running under systemd, so just add User/Group with
the configured user to the system unit.
If libaudit support is enabled, add AmbientCapabilities=CAP_AUDIT_WRITE
so that we can still write to the audit log.
Luca Boccassi [Mon, 20 Mar 2023 01:50:53 +0000 (01:50 +0000)]
spec: add ProcessFD to GetConnectionCredentials()
Make D-Bus implementations return a file descriptor
pinning the process as part of the credentials on
platforms that implement such concept, like Linux.
Pinning the process allows to defend against PID
reuse attacks, making authentication by
service/cgroup possible.
Xin Shi [Fri, 28 Jul 2023 01:38:24 +0000 (09:38 +0800)]
dbus-daemon: Avoid known options being interpreted as optional arguments
The man page and --help imply that
dbus-daemon --print-address --print-pid
is a valid/useful thing to do, but because --print-address takes an
optional argument, it is ambiguous whether --print-pid is meant to
be the argument for --print-address (same as --print-address=--print-pid)
or a new option (same as --print-address=1 --print-pid). In fact,
before this commit, the dbus-daemon would interpret --print-pid as
the optional argument to --print-address, and then fail to parse it
because it isn't an integer.
Because none of our options are syntactically valid as arguments for
any option that takes an optional argument, we can avoid the ambiguity
by delaying parsing of optional arguments until all known options
have been tried.
dbus-sysdeps-unix: Handle empty supplementary group list
It is valid for getsockopt(SO_PEERGROUPS) to return len=0; that
indicates the process has no supplementary groups. Rather than failing,
simply use the returned empty list (and add the primary GID to it).
Without this change, calling GetConnectionCredentials on a bus name
owned by a process with no supplementary groups does not return the
UnixGroupIDs field, even though it is easy to determine that the process
only has one GID (the primary GID).
Barnabás Pőcze [Tue, 13 Jun 2023 16:12:26 +0000 (18:12 +0200)]
meson: Override "dbus-1" dependency name
Since meson 0.54.0, it is possible to override a dependency name,
so do that to make it easy to use dbus as a subproject. After this
change, simply
dependency('dbus-1')
will fall back to the subproject automatically and there is no need
for using `fallback` keyword argument. Of course this assumes that
the dbus source tree is at subprojects/dbus-1 and not subprojects/dbus
but it is easy to achieve that.
If the dbus source tree for some reason needs to be at subprojects/dbus,
dependency('dbus-1', fallback: 'dbus')
may be used, which still has the advantage of not needing to
depend on the variable names in the dbus build definitions.
Simon McVittie [Tue, 13 Jun 2023 12:59:21 +0000 (13:59 +0100)]
CI: Enable "debian mingw64 meson debug" by default
This gives us coverage for Meson mingw-w64 by default, but
cross-compiling from Debian with MSVCRT rather than a native compilation
on Windows with UCRT. When combined with "windows msys64 ucrt64 cmake",
this fills in most of the missing coverage caused by disabling
windows-meson-mingw-ucrt64 to work around dbus#462.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ralf Habacker [Mon, 12 Jun 2023 17:55:05 +0000 (19:55 +0200)]
CI: Fix problem with configuration when cross building with cmake
Due to an adaptation of an rpm macro for cross-compiling with cmake, there
was a problem with the previous method of using the current directory as
the build directory. Instead, the command line options provided by cmake
are now used to define the source and build directories, which provide more
stable behavior.
Simon McVittie [Tue, 6 Jun 2023 12:07:04 +0000 (13:07 +0100)]
meson: Disable some warnings when asserts/checks are disabled
Some labels are only used when checks are enabled, and some variables
are only used when assertions and/or checks are enabled. Instead of
cluttering the code with extra #ifdefs, we silence those warnings:
they're harmless in this case. We already do this in Autotools.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Tue, 6 Jun 2023 12:05:41 +0000 (13:05 +0100)]
sysdeps: Correct fallback signature of Linux close_range()
Linux generally declares syscalls with flags as type int. It's the same
ABI, but a slightly different API, and it seems better for our fallback
definition to match it exactly.
Related to dbus/dbus#453.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 5 Jun 2023 17:51:22 +0000 (18:51 +0100)]
monitor test: Reproduce dbus/dbus#457
The exact failure mode reported in dbus/dbus#457 is quite difficult
to achieve in a reliable way in a unit test, because we'd have to send
enough messages to a client to fill up its queue, then stop that client
from draining its queue, while still triggering a message that gets a
reply from the bus driver. However, we can trigger the same crash in a
slightly different way by not allowing the client to receive a
particular message. I chose NameAcquired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
hongjinghao [Mon, 5 Jun 2023 17:17:06 +0000 (18:17 +0100)]
bus: Assign a serial number for messages from the driver
Normally, it's enough to rely on a message being given a serial number
by the DBusConnection just before it is actually sent. However, in the
rare case where the policy blocks the driver from sending a message
(due to a deny rule or the outgoing message quota being full), we need
to get a valid serial number sooner, so that we can copy it into the
DBUS_HEADER_FIELD_REPLY_SERIAL field (which is mandatory) in the error
message sent to monitors. Otherwise, the dbus-daemon will crash with
an assertion failure if at least one Monitoring client is attached,
because zero is not a valid serial number to copy.
This fixes a denial-of-service vulnerability: if a privileged user is
monitoring the well-known system bus using a Monitoring client like
dbus-monitor or `busctl monitor`, then an unprivileged user can cause
denial-of-service by triggering this crash. A mitigation for this
vulnerability is to avoid attaching Monitoring clients to the system
bus when they are not needed. If there are no Monitoring clients, then
the vulnerable code is not reached.
Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus/dbus#457
Simon McVittie [Tue, 6 Jun 2023 09:41:35 +0000 (10:41 +0100)]
README: Mention not opening merge requests for security issues
The dbus maintainers can open confidential merge requests by using a
private git repository, but other contributors (including most security
researchers) cannot, so the safest simple recommendation is no merge
requests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Luca Boccassi [Mon, 20 Mar 2023 01:40:20 +0000 (01:40 +0000)]
Support /proc in _dbus_file_get_content
procfs has special semantics: most files are 0 size,
only one read can be done on a file, and they are
not larger than 4MB. Enhance _dbus_file_get_content()
so that we can read files from /proc with it.
Barnabás Pőcze [Thu, 4 May 2023 14:37:57 +0000 (16:37 +0200)]
dbus-spawn-win: use `_DBUS_FUNCTION_NAME` instead of `__FUNCTION__`
dbus-internals.h already defines a macro which expands to the name
of the current function based on C standard version, etc. So use
that instead of hard-coding `__FUNCTION__`.
Barnabás Pőcze [Thu, 4 May 2023 14:26:31 +0000 (16:26 +0200)]
dbus-internals: use `_DBUS_FUNCTION_NAME` in `_dbus_verbose()`
dbus-internals.h already defines a macro which expands to the name
of the current function based on C standard version, etc. So use
that instead of hard-coding `__FUNCTION__`.
Simon McVittie [Fri, 12 May 2023 17:35:13 +0000 (18:35 +0100)]
CI: Disable native Windows builds for now
These are extremely slow (the image build is currently at 36 minutes
and still running) which is standing in the way of us having functional
CI at all. They can be re-enabled if someone will maintain them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
projects / thirdparty / dbus.git / log
