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>
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.
Fixes: 145fb99b (untitled refactoring commit, 2006-12-12)
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
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>
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>
Test it's possible to consume libdbus as a subproject.
Suggested-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
To make the consume libdbus via Meson's subproject use case more useful,
introduce message_bus and tools command line options which control if
the D-Bus daemon and/or the tools are build. The idea here is that
depending projects are interested only in the library.
The strong recommendation is only to build libdbus as static library:
libdbus_dep = dependency(
'dbus-1',
required: get_option('libdbus'),
fallback: ['dbus', 'libdbus_dep'],
default_options: [
'default_library=static',
'embedded_tests=false',
'message_bus=false',
'modular_tests=disabled',
'tools=false',
],
)
This ensures that any installed D-Bus infrastructure on the target
system is not overwritten.
Signed-off-by: Daniel Wagner <dwagner@suse.de>
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
After 6e48c317 the test-apparmor-activation test fails as it can no
longer access the dbus socket in /tmp. This commit updates the apparmor
profile used within the test
In some more complicated loops, we do need to use 'goto' to exit from
an inner loop, or to jump to cleanup or an increment of an iterator
immediately before the next loop iteration. However, in these simple
cases, jumping to a label immediately before the 'while' keyword is
unnecessary: we can use an equivalent 'continue' statement for flow
control.
This makes it easier for maintainers to notice the loops where we are
doing something more complicated, which still use 'goto', and know
that they need to pay more attention in those cases.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The TCL-derived code is under its own license, so the overall license
of the file is (AFL-2.1 OR GPL-2.0-or-later) AND TCL.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Red Hat have previously given permission for relicensing, and all
subsequent contributions to this file were trivial.
Signed-off-by: Simon McVittie <smcv@collabora.com>
With permission from Philip Withnall on behalf of Endless, me on behalf
of Collabora, and relying on previous permission from Red Hat
representatives.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was contributed by Ralf Habacker and later edited by me, with a
trivial change from Thomas Zimmermann which I don't think affects its
copyright.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was contributed by Ralf Habacker, with a trivial change from
Philip Withnall which I don't think affects its copyright.
Signed-off-by: Simon McVittie <smcv@collabora.com>
All significant contributions to this file were from companies or
individuals that gave permission for relicensing to MIT (I have assumed
that trivial changes from Marcus Brinkmann and Kjartan Maraas were too
small to affect copyright status).
Signed-off-by: Simon McVittie <smcv@collabora.com>
All significant contributions to this file were from companies that gave
permission for relicensing to MIT (I have assumed that trivial changes
from Marcus Brinkmann and Ralf Habacker were too small to affect
copyright status).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The license for this file was never stated, but all contributions to it
have been from Red Hat or Collabora, and representatives of both
companies gave permission for MIT relicensing in 2007.
Signed-off-by: Simon McVittie <smcv@collabora.com>
dbus_message_unref() is in principle able to handle a NULL parameter, but
causes the program to abort when `fatal_warnings_on_check_failed` is set.
Therefore the call with a NULL parameter is avoided from now on.
Fixes#422
This seems to have been intended to give a more specific error message
if the method call failed, but it will not have been effective, because
dbus_connection_send_with_reply_and_block() ends with a check for ERROR
messages using dbus_set_error_from_message(). This means that if the
reply was an ERROR message, it will already have been converted into a
DBusError by the time call_method() regains control.
Signed-off-by: Simon McVittie <smcv@collabora.com>
An unrelated branch failed CI with this assertion failure:
26: dbus[6768]: error: arguments to dbus_set_error() were incorrect,
assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in
file ...\dbus-errors.c line 365.
Looking at the test, this seems to be the most likely candidate for
this bug in error handling, which is masking whatever the real cause
for the failure was (we can't tell from here). If
dbus_connection_send_with_reply_and_block() returns NULL, then it should
already have set the error.
Fixing this bug in the error handling will hopefully give us a better
error message for the actual failure if it happens again.
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>
In debug builds with "embedded tests" enabled, these will automatically
be used as input for the message-internals test.
Some of the messages themselves are output from a fuzzer, others are
simplifications to include only one reason for lack of validity per
message.
I've included an annotated hex-dump for each message here, but the dbus
test suite doesn't currently know how to convert hex to binary, so I've
also committed the corresponding binary. See the comment at the top of
each hex-dump for how to create the binary version (which requires the
xxd tool shipped with vim).
It would be nice for the dbus test suite to be able to convert the
annotated hex-dump to binary, either at build-time with a Python script
or at runtime by loading the text file and decoding the hex, but I don't
want to block on that for dbus/dbus#413 and dbus/dbus#418.
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Signed-off-by: Simon McVittie <smcv@collabora.com>
FreeBSD 13.0 has reached EOL and it appears packages
are built against a newer baseline now, so we end up
with missing symbol errors:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
It also appears that the fdpass test still fails on 13.1, so update the
condition to less than 14.0
I am trying to run cross-compiled tests in QEMU with the build directory
mounted via smbfs, and therefore creating the sockets in the CWD does not
work. Using DBUS_TEST_SOCKET_DIR (/tmp by default) allows me to run the
tests successfully.
Debug messages in a background thread can corrupt the machine-readable
TAP output, and in particular GWin32AppInfo emits debug messages from
a background thread when we link to libgio.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/414
Signed-off-by: Simon McVittie <smcv@collabora.com>
The /odd-limit/at test passes on 13.1 and 14.0 images, but fails on 13.1.
Debugging has not given me any useful hints why this may be the case, so
disable this test on 13.0 for now.
This allows us to drop the ci_test_fatal: "no" override which will ensure
that any FreeBSD regressions are caught.
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.
This is really three separate test-cases: one for traditional
activation as a direct child process of the dbus-daemon, and two for
traditional activation (successful and failing) via the setuid
dbus-daemon-launch-helper on Unix.
The ones where activation succeeds extremely slow, as a result of the
instrumentation for simulating malloc() failures combined with a large
number of memory operations, particularly when using AddressSanitizer.
Splitting up "OOM" tests like these has a disproportionately good impact
on the time they take, because the simulated malloc() failure
instrumentation repeats the entire test making the first malloc() fail,
then making the second malloc() fail, and so on. For allocation failures
in the second half of the test, this means we repeat the first half of
the test with no malloc() failures a very large number of times, which
is not a good use of time, because we already tested it successfully.
Even when not using the "OOM" instrumentation, splitting up these tests
lets them run in parallel, which is also a major time saving.
Needless to say, this speeds up testing considerably. On my modern but
unexceptional x86 laptop, in a typical debug build with Meson, the old
dispatch test took just over 21 minutes, which drops to about 40 seconds
each for the new normal-activation and helper-activation tests (and for
most of that time, they're running in parallel, so the wall-clock time
taken for the whole test suite is somewhere around a minute).
In a debug build with Meson, gcc and AddressSanitizer, the old dispatch
test takes longer than my patience will allow, and the new separate
tests take about 5-6 minutes each. Reduce their timeout accordingly, but
not as far as the default for slow tests (5 minutes) to allow some
headroom for AddressSanitizer or slower systems.
The failed-helper-activation test is almost instantaneous, and no longer
needs to be marked as slow.
Signed-off-by: Simon McVittie <smcv@collabora.com>
