Simon McVittie [Wed, 25 Sep 2024 13:41:48 +0000 (14:41 +0100)]
test: Always initialize an "out" parameter
check_valid_fd() does not touch its second parameter if the fd is not,
in fact, a valid fd. Initialize the "out" parameter to the opposite
of the value we are hoping for, so that both assertions will fail if
there is a problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Wed, 25 Sep 2024 13:40:16 +0000 (14:40 +0100)]
sysdeps-unix: Always initialize flags for syslog()
If passed an invalid DBusSystemLogSeverity, the default case for the
switch construct is to crash out with an assertion failure, but the
assertion failure itself is not compiled in if we are doing a production
build without assertions.
Detected by compiling with gcc 14, which does some static analysis
by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Wed, 25 Sep 2024 13:36:13 +0000 (14:36 +0100)]
sysdeps: Avoid passing possibly null port-number string to printf %s
gcc 14 detects that port can be NULL here, which is technically invalid
to pass to printf (although many implementations print it as "(null)").
Becuase we're using getaddrinfo(), we treat a NULL service (port number
string) as a request to listen on "port 0", meaning we ask the kernel to
assign an arbitrary nonzero port for us; when printing addresses in
error messages, treating that as port 0 seems reasonable.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Alyssa Ross [Mon, 22 Jul 2024 08:08:05 +0000 (10:08 +0200)]
dbus-sysdeps-unix: don't add (uid_t)-1 to creds
If I set a breakpoint on the call to _dbus_credentials_add_unix_uid
further down in this function and run the loopback test, I can see
that sometimes it's getting called with a uid of 4294967295. This is
not intended, but happens because the -1 value returned from
SO_PEERCRED is interpreted as a uid of 4294967295, because if uid_t is
unsigned, it won't be sign extended when assigned to uid_read.
As far as I can tell, every other API used in this function to get
uid/gid on some system returns an error when there's no credential
information (e.g. on a non-unix socket), rather than returning -1, so
they shouldn't have to do this check.
Alyssa Ross [Sun, 28 Jul 2024 10:50:37 +0000 (12:50 +0200)]
test: use "tty" group rather than "bin"
Unlike "bin", "tty" actually means something on modern Linux distros,
and is used by a default udev rule, so it's more likely to exist on
distros than a group that just exists for historical compatibility
with who knows what.
"tty" exists on macOS, Debian, and Fedora (the criteria used for
choosing "bin" in f2905def ("policy tests: Use bin rather than
nogroup, wheel, or root")), but also fixes running the bus test for me
on NixOS, which has "tty" but not "bin".
Closes: https://gitlab.freedesktop.org/dbus/dbus/-/issues/514 Signed-off-by: Alyssa Ross <hi@alyssa.is>
Alyssa Ross [Sun, 21 Jul 2024 12:24:13 +0000 (14:24 +0200)]
meson: fix name of DBUS_ENABLE_LAUNCHD macro
This is the name used previously by autoconf, and still used by the C
code. Presumably this meant that the launchd ended up never being
built with Meson, even if launchd support was enabled.
Signed-off-by: Alyssa Ross <hi@alyssa.is> Fixes: cd2e3826 ("Add Meson build system")
Simon McVittie [Wed, 23 Aug 2023 11:04:33 +0000 (12:04 +0100)]
sysdeps: Remove _dbus_string_append_int()
It's a wrapper around snprintf(), so we are not gaining any efficiency
versus _dbus_string_append_printf(), and might as well use the more
general function instead. Doing it this way might even be a little *more*
efficient, since it reduces reallocations; it's certainly more concise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Wed, 23 Aug 2023 10:57:44 +0000 (11:57 +0100)]
sysdeps: Remove _dbus_string_append_uint()
It's a wrapper around snprintf(), so we are not gaining any efficiency
versus _dbus_string_append_printf(), and might as well use the more
general function instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gitlab.fd.o/bustle/bustle points to the old archived project. The new
version has been rewritten in Rust and is now hosted at
gitlab.gnome.org/World/bustle
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
sysdeps-win: Fix autolaunch: regression on Windows
Commit f20a05f60f6f included in dbus-1.15.0 broke autolaunch: on
Windows. autolaunch_custom_command_line_parameter shall be initalized
to null as it is later used in only one place in the code, with this
ternary:
hongjinghao [Thu, 4 Jan 2024 07:15:53 +0000 (15:15 +0800)]
Do not crash when reloading configuration with > 128 dirs
When `dbus-daemon` sets more than 128 directories for `XDG_DATA_DIRS`,
none of the elements in `new_dirs` will be `NULL`, which resulted in
these loops reading out-of-bounds (undefined behaviour). In practice
this led to a crash.
To avoid this, make sure to stop iteration at the end of the array.
instead of using has_header use check_header to confirm the header
works. This is necessary to get the meson build to work with Visual
Studio 2022. It has <stdatomic.h> but it does not actually work when
compiling a C program. A minimal C program that include <stdatomic.h>
fails with the following errors:
Simon McVittie [Fri, 1 Dec 2023 19:10:50 +0000 (19:10 +0000)]
CI: Set language environment variables to safe values
Recent versions of glibc support C.UTF-8 natively, and both Debian and
openSUSE (which we use for our CI) have been patching it into our glibc
versions for several years before that.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/488 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 1 Dec 2023 19:03:49 +0000 (19:03 +0000)]
CI: Don't re-run the tests when preparing to build as a subproject
After running the test suite, we don't need (or want) to re-run the test
suite as a side-effect of producing a dist tarball. Historically, this
test-case used Autotools `make dist`, not `make distcheck`, but when
we removed the Autotools build system, it was replaced with
`meson dist` (similar to Autotools `make distcheck`). Change that to
`meson dist --no-tests`, which is more like Autotools `make dist` as
originally intended.
In particular, when we re-ran the test suite, we weren't filtering out
the time-consuming and timeout-prone tests that emulate malloc()
failures, which we don't normally intend to run in CI.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/489 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 1 Dec 2023 19:00:20 +0000 (19:00 +0000)]
CI: Remove meson-dist and cmake-dist build systems
Before we removed the Autotools build system, these meant: do a
`make dist` with Autotools, then unpack the resulting tarball, and build
it with Meson or CMake (as appropriate). This was important because the
contents of an Autotools `make dist` differed significantly from what's
in git: only the files that were explicitly declared as sources in the
Autotools build system were distributed, and Autotools would also add its
own generated cruft.
Now that we're doing releases with Meson, the official source release
artifact is basically `git archive`, so there's much less need to
distinguish between official source releases and what's in git, and these
variant build systems became simple aliases for meson and cmake.
Remove those aliases from tools/ci-build.sh, and stop using them in
.gitlab-ci.yml.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ralf Habacker [Mon, 21 Aug 2023 21:34:10 +0000 (23:34 +0200)]
Remove autotools support from CI jobs
The 'debian mingw32 autotools debug' job was replaced with a corresponding
meson related job named 'debian mingw32 meson debug' and the remaining
autotools related jobs were removed.
The drop in replacement job for 'debian mingw64 autotools' is
'debian mingw32 meson' and is now build by default.
time: use dbus_int64_t for seconds instead of long
On 32 bit systems long will overflow in 2038, causing complete breakage.
This is confirmed by running dbus's test suite on a 32 bit system
with system time set to 2040 (and configured to use 64 bit time_t of course).
Note that both timespec and timeval are specified with time_t for the
seconds component. This should propagate everywhere where that data is
passed and stored, but previously _dbus_get_monotonic_time() and
_dbus_get_monotonic_time() would truncate it to long.
Also add a function for parsing dbus_int64_t from
files, as existing functions can only handle long.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Simon McVittie [Thu, 29 Jun 2023 16:51:48 +0000 (17:51 +0100)]
userdb: Use "goto out" pattern for _dbus_groups_from_uid()
This makes it easier to verify that _dbus_user_database_unlock_system()
is called on all exit paths. The only early-return is when locking the
userdb failed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Thu, 29 Jun 2023 16:28:40 +0000 (17:28 +0100)]
sysdeps: Improve error reporting for looking up a user
Our implementation always assumed that both code paths set errno, but
according to their API documentation, getpwnam_r and getpwuid_r actually
don't: they *return* a code from the same pseudo-enum as errno. They
also return 0 (but with a NULL struct passwd) if the user is not found,
which these APIs don't count as an error (but we do).
Similarly, in the legacy getpwnam/getpwuid code path, it is unspecified
whether looking up a nonexistent user will set errno or not.
Having retrieved an errno-like error code, we might as well use it in
the human-readable message and not just the machine-readable code,
because the human-readable message is what ends up in the system log.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343 Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Thu, 29 Jun 2023 16:00:58 +0000 (17:00 +0100)]
sysdeps-unix: Deduplicate error handling for getpwnam and getpwnam_r
The only difference between these was that we only needed to allocate
and free buf in the getpwnam_r case. We expect that all reasonable
Unix platforms will have getpwnam_r (it's in POSIX) so adding a no-op
dbus_free(NULL) to the getpwnam code path seems harmless.
This will be helpful when we make the error handling better, in a
subsequent commit.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343 Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
projects / thirdparty / dbus.git / log
