This is not used on Windows (in fact it's only used in the
dbus-cleanup-sockets(1) tool) so it's OK for it to have a value like /tmp
that would be inappropriate on Windows. Make that more obvious.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it more obvious that it is currently only used on Unix,
and therefore it's OK for it to have a default that wouldn't work
on Windows.
The non-default CMake build system already didn't set the variable when
building for Windows.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To achieve comparable results with Meson, the test environment should
provide the same set of environment variables when used in the source
code or the test environment.
Resolves: dbus/dbus#541
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Some distributions are known to have shipped dbus 1.15.x as though it
was a stable release, and it isn't clear whether they knew that we use
the odd/even versioning convention like GLib does.
If we add a -alpha, -beta, -rc suffix to development versions starting
from 1.17.0, then distros that know we use odd/even versioning will
know that our development versions are not a stable-branch, and so will
distros that mistakenly think we use the "semantic versioning"
versioning convention popularized by <https://semver.org/>.
(We intentionally do not use semver, because semver would require us to
ship a new minor version every time we add new API, and we do not have
the resources to provide security support for an unlimited number of
minor versions in parallel: we need to be able to nominate a subset of
our releases as having longer-term security support, in a way that signals
to distros that these are the releases they should prefer to ship.)
CMake's `project()` doesn't allow this version number format[1], but
we intend to use version numbers where the (major, minor, micro) tuple
is enough to uniquely identify a release, so we can just tell CMake our
version number without the suffix and there will be no ambiguity.
Similarly, the dash is not allowed in GNU ld version scripts, so use
the form of the version number without the suffix there.
[1] https://gitlab.kitware.com/cmake/cmake/-/issues/16716
Helps: dbus#530
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, the CMake build enabled tests by default, and enabled both
modular and intrusive (embedded) tests with a single option. This is
a really bad idea if anyone is using CMake-built binaries in production.
DBUS_BUILD_TESTS now enables only the modular tests, which are safe to
enable in production builds.
A new DBUS_ENABLE_INTRUSIVE_TESTS option enables the intrusive test
instrumentation.
To preserve existing test coverage, explicitly enable the intrusive
tests in most CMake-based Gitlab-CI jobs (Debian native, openSUSE native,
Windows).
In jobs that have a mirrored pair of production/debug builds (openSUSE
and Debian mingw32/mingw64 cmake), instead we leave the production
build as-is and only build full test coverage in the debug build.
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hopefully helps to get across the point that enabling these tests
adds instrumentation to libdbus and dbus-daemon, with a potentially
significant impact on code size, performance and security.
To avoid a huge diffstat which would be difficult to review, the cpp
macro that is checked by most of the C code is still
DBUS_ENABLE_EMBEDDED_TESTS, which is defined or undefined under exactly
the same conditions as the new DBUS_ENABLE_INTRUSIVE_TESTS.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/537
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
The DBus1_xxx variables defined in DBusConfig.cmake for Windows builds
are currently hard-coded values and independent of those of the underlying
cmake target.
To avoid this, these values are retrieved from the corresponding cmake
target. In addition, the cmake allows the construction of the resulting
relocatable runtime paths.
These were/are used as autoconf/CMake variable names, but were never
used by C code, so there's no need to export them as macros.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: dca6591f ("Keep cmake defines GLIB_VERSION_... in sync with autotools.")
Fixes: cd2e3826 ("Add Meson build system")
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>
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>
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.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Some of the symbols we check for, such as close_range(), are only
declared in their corresponding header files if _GNU_SOURCE was
defined.
Resolves: dbus/dbus#453
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Signed-off-by: Luca Boccassi <bluca@debian.org>
I've erred on the side of caution and treated the COPYING-CMAKE-SCRIPTS
license (a BSD-3-Clause variation) as its own distinct license.
Co-authored-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
These environment variables are used by GLib's g_test_build_filename()
and related convenience functions, which make it easier for unit tests
to find data files in a way that works for both build-time tests and
"as-installed" tests. During "as-installed" testing, both variables
will normally be unset, and GLib uses the directory containing the
executable. In most cases that results in the right thing happening, and
this will also be true for dbus, since we install the test executables
in ${libexecdir}/installed-tests, helper executables in the same place,
and test data in ${libexecdir}/installed-tests/data.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These static assertions fail on CHERI-enabled architectures such as Arm
Morello, where pointers are 128 bits. Architectures with 128-bit pointers
were not supported in DBus 1.10, so we can skip the checks for DBus 1.10
structure layout compatibility for architectures with pointer size > 64 bit.
This header is GCC specific header that on my system just contains
`#include_next <limits.h>`. FreeBSD also provides this header but it
contains a `#warning` that it should not be used. Replace the one use
with `#include <limit.h>` and drop the configure checks.
This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
DBus1Config.cmake.in relies on DBus1Targets.cmake, which is generated
by CMake. DBus1Config.pkgconfig.in uses pkg-config and is independent
of CMake.
Signed-off-by: Simon McVittie <smcv@collabora.com>
dbus-sysdeps-unix.c checks for DBUS_USE_SYNC using 0/1 checks not defined
checks, so we should be using #cmakedefine01. This fixes lots of -Wundef
warnings when compiling for FreeBSD and ensures that we actually use
atomics instead of the pthread fallback there.
Unsupported warnings are detected by cmake through errors during
compilation, which causes g++ not to detect them, since they are
only output as warnings. Setting -Werror ensures this.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This was added to the Linux kernel in version 5.9, but the wrapper
wasn't added to glibc until 2.34. Adding our own wrapper for the
system call means we can use close_range() on Debian 11 and
contemporary distributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This lets us use CLOSE_RANGE_CLOEXEC whenever the kernel headers
support it, even if glibc doesn't include this header via unistd.h yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The version with no flags set, which is a slight generalization of
closefrom(), is available on recent Linux and FreeBSD.
The version with CLOSE_RANGE_CLOEXEC is Linux-specific.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
<dbus/dbus-arch-deps.h> is architecture-dependent, and compilers have
not traditionally supported an installation path for architecture-specific
headers (Debian-based systems have /usr/include/${multiarch_tuple}, but
that isn't portable beyond Debian). When dbus was built using Autotools,
dependent projects that use CMake need to look for this header in the
right place.
Unfortunately, it seems that at least recent versions of CMake will
ignore the HINTS we get from pkg-config if they are told to search in
a non-standard prefix via ${DBus1_ROOT}.
Look for dbus-arch-deps.h in a directory derived from the filename of
the CMake config file, before trying the normal search algorithm. The
CMake config file is in ${libdir}, and so is the architecture-specific
header, so this should work reasonably reliably.
According to the CMake documentation, if we search for the same thing
multiple times, the first successful result will be used; and searching
with NO_DEFAULT_PATH is the official way to prepend things to the
search order.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/314
Signed-off-by: Simon McVittie <smcv@collabora.com>
