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>
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>
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>
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>
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.
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.
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>
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>
We've had a request for a 1.14.x stable-branch, but the Containers
interface is only partially implemented, not yet described in the
D-Bus Specification, and not ready to be part of our API guarantees.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The first two definitions are required to fix cmake build error when
compiling with -Werror=undef on Windows.
The last one completes having HAVE_DECL_xxx definitions.
Traditional activation is enabled/disabled with the cmake configure
parameter -DENABLE_TRADITIONAL_ACTIVATION, which is enabled by default.
This was added to the Autotools build system as part of dbus/dbus!107
but until now was not possible to disable when building with CMake.
Previously, only the Autotools build system could do this. This commit
includes most of the same features as in the Autotools build, although
not the user-session semantics, which will be added separately.
Systemd support is controlled by the cmake variable ENABLE_SYSTEMD, which can
have the values OFF, ON and AUTO, the latter enabling support by default if
the required libraries are available.
With WITH_SYSTEMD_SYSTEMUNITDIR a custom installation location can be specified.
If it is not specified, the related install path is determined from the installed
systemd package, if present.
POSIX.1-2001 and POSIX.1-2008 specifies include <poll.h> so use that
rather than the non-standard/legacy include <sys/poll.h>.
This fixes the following warnings when building with musl libc:
1 | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^~~~~~~
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Use getrandom(2) and fall back to /dev/urandom if it is missing or if it
fails some any reason.
This solves problem where dbus-uuidgen is called from a chroot which
lacks /dev/urandom.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
In the Autotools build system, the AC_USE_SYSTEM_EXTENSIONS macro
defines __EXTENSIONS__ and _POSIX_PTHREAD_SEMANTICS, and we set the
others explicitly when compiling for a Solaris host.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Solaris 2.3 and 2.4 took their getpwnam_r() signature from draft 6
of the POSIX threads standard. Since Solaris 2.5 (1995), defining
_POSIX_PTHREAD_SEMANTICS opts-in to the non-draft version of
getpwnam_r(), and since Solaris 11.4 (2018), the non-draft version is
the default.
We already use AC_USE_SYSTEM_EXTENSIONS, which defines
_POSIX_PTHREAD_SEMANTICS, among other useful macros.
Thanks to Alan Coopersmith for assistance with Solaris history.
Signed-off-by: Simon McVittie <smcv@collabora.com>
va_copy() is a C99 feature, and should be widely supported by now.
gcc in strict C89 mode implements an equivalent __va_copy() instead.
MSVC 2013 implements va_copy(), but at the moment we still aim to support
MSVC 2010 and 2012, which don't have it. However, we know that in
Windows ABIs, va_list is a pointer, so we can use
_DBUS_VA_COPY_ASSIGN. We do not support MSVC for Autotools builds, only
CMake, due to its non-Unixish command-line interface.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have considerable anecdotal evidence that every relevant compiler
supports at least the small part of ISO varargs syntax that we need
here, because tools/tool-common.h has contained
#define VERBOSE(...) do {} while (0)
since dbus 1.9.2 (2014) and nobody has complained yet. With that in
mind, let's simplify.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For test case execution, CheckCSourceCompiles is now used instead
of try_compile and the determination of DBUS_VA_AS_ARRAY is
performed with a separate test instead of evaluating the result
of HAVE_VA_COPY and HAVE___VA_COPY.
The tests are performed for all supported compilers. Since older
MSVC compilers (< 2013) do not support va_copy(), the macro
_DBUS_VA_ASSIGN(a1,a2) with the implementation { a1 = a2; } is used
as a fallback.
