Unlike the message-internals test, these do not rely on extra debug
instrumentation in libdbus, and so can be used for "as-installed"
testing. (However, they do require GLib.)
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>
(cherry picked from commit 3ef342410a)
(cherry picked from commit 6b88e768d8)
[backport to 1.12.x: resolve conflicts; call _dbus_header_delete_field
directly because _dbus_message_remove_unknown_fields didn't yet exist
in this branch]
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>
(cherry picked from commit 37e0125943)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit bbf5ef008a)
[backport to 1.12.x: resolve conflicts in CMake build system]
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>
(cherry picked from commit d633016f73)
[backport to 1.14.x: discard Meson build system updates]
(cherry picked from commit c0bfcc0978)
[backport to 1.12.x: resolve conflicts vs. Autotools before 09076dfe]
The session dbus-daemon won't necessarily be run immediately on login
if we are using systemd socket activation for it, and the transient
services directory $XDG_RUNTIME_DIR/dbus-1/services isn't created until
it's actually run. Ping the dbus-daemon to make sure it's available.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1005889
(cherry picked from commit 47a4bdfaf8)
Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
are enabled (which suggests that no FreeBSD user has run those tests
successfully).
We already include <netinet/in.h> in other places with no conditions
or checks other than "is Unix", so apparently it's portable enough that
specifically testing for its presence is not necessary. POSIX requires it
to exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f0e526bca8)
This version is for the dbus-1.12 branch, and doesn't rely on dbus!153
or dbus!120.
Reproduces: dbus#294
Reproduces: CVE-2020-12049
Reproduces: GHSL-2020-057
Signed-off-by: Simon McVittie <smcv@collabora.com>
In an unprivileged container, uid 0 doesn't have CAP_SYS_RESOURCE, so
we can't expect the dbus-daemon to be able to escalate its fd limit.
This can be reproduced using bubblewrap:
sudo bwrap \
--cap-drop CAP_SYS_RESOURCE \
--ro-bind / / \
--dev /dev \
env \
DBUS_TEST_DAEMON=.../bus/dbus-daemon \
DBUS_TEST_DATA=.../test/data \
.../test/test-dbus-daemon \
-p /fd-limit \
--verbose
Bug-Debian: https://bugs.debian.org/908092
We don't actually complete successful authentication, because that
would require us to generate a cookie and compute the correct SHA1,
which is difficult to do in a deterministic authentication script.
However, we do assert that dbus#269 (CVE-2019-12749) has been fixed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
MSYS2 has enough of a Unixish environment to run Autotools, but
apparently not enough of a Unixish environment to have functional
permissions.
Closes: dbus#216
(cherry picked from commit 14f46d14a0)
AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest autoconf-archive release,
version 2019.01.06, which is inconveniently new, so bundle everything
we need for the moment.
This requires us to stop using the deprecated CODE_COVERAGE_LDFLAGS
(which we still used to support older versions of autoconf-archive)
and replace them with CODE_COVERAGE_LIBS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2938c2125e)
Closes: dbus#265
The timeout we're using here is 0.5s (500ms), but the actual time taken
is unbounded, because the OS scheduler might not schedule our process
for an arbitrary length of time after we become runnable.
We previously allowed up to 1 second, but in the CI jobs for dbus!9
and dbus!18 we've seen this take up to 3.4 seconds (presumably
because other tests, or other jobs running on the same shared
infrastructure, starved this process). Allow up to 10 seconds to guard
against spurious failures.
The timeout used in the production system.conf is 150 seconds (2½
minutes), and we're only using the shorter 500ms timeout here to make
the test complete more quickly, so ±10 seconds is relatively
insignificant: the main thing is that it's finite.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 20e6eb7cd1)
For example, this can be the case in bubblewrap or Debian pbuilder after
unsharing the network namespace:
bwrap \
--bind / / \
--dev-bind /dev /dev \
--bind /dev/shm /dev/shm \
--bind /dev/pts /dev/pts \
--unshare-net \
${builddir}/test/test-loopback --tap
...
ok 1 /connect/tcp # SKIP Name resolution does not work here:
getaddrinfo("127.0.0.1", "0", {flags=ADDRCONFIG, family=INET,
socktype=STREAM, protocol=TCP}): Name or service not known
On some systems this can be circumvented by using nss_wrapper from
<https://cwrap.org/nss_wrapper.html>:
cat > hosts <<EOF
127.0.0.1 localhost
EOF
bwrap \
... \
env \
LD_PRELOAD=libnss_wrapper.so \
NSS_WRAPPER_HOSTS=$(pwd)/hosts \
${builddir}/test/test-loopback --tap
...
# listening at tcp:host=127.0.0.1,port=39219,family=ipv4,guid=...
but for systems where that does't work, we should be prepared to skip
the affected tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit f1faafd59b)
Pathological autobuilder environments might not list localhost in
/etc/hosts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit 4cfc7de30d)
Minimal autobuilder environments don't always have working TCP,
so we may need to skip TCP tests. Make sure we test the equivalent
code paths via Unix sockets in those environments.
One notable exception is test/fdpass.c, which uses TCP as a transport
that is known not to be able to carry Unix fds; this needs to continue
to use TCP.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit cb7dd5bfcc)
This expands test coverage, and lets us reuse the test for other
address schemes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
(cherry picked from commit b19c9e2f26)
Based on code contributed by Manish Narang. This is not included in the
automated test suite, because it isn't reliable on heavily-loaded
automatic test infrastructure like Travis-CI.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the test to the CMake build system too, as requested]
[smcv: Convert into a manual test]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
(cherry picked from commit 0b1e292860)
This will be used in tests later in the branch.
Sadly we can't use GLIB_VERSION_2_44 unless we are willing to have a
hard dependency on GLib 2.44, which would force us to do all our
Travis-CI builds in Docker containers rather than in ye olde base
system, and that adds 50% to the time taken to do builds.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Rebase onto 1.13.x branch, fix minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
(cherry picked from commit d5742550ca)
Tests that brute-force OOM code paths can be rather slow.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 5c91d85f3e)
DBusLoop isn't thread-safe, so we can't use it to test multi-threaded
situations.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit f127c8e110)
[smcv: Adjust for older codebase]
This also covers _dbus_server_new_for_socket(), which is one of the
worse places in terms of complexity of the error-unwinding path
(3 labels).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
(cherry picked from commit ac6c4d384d)
These were in git but not distributed in source tarballs, and in fact
not hooked up to the Autotools build system at all.
test/data/valid-introspection-files was mentioned in the CMake build
system (copied from the source directory to the build directory), but
according to `git grep` is not used for anything.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
test-bus exercises the parser by trying to parse every file in these
directories. A couple of files were accidentally left out, meaning
those parsing code paths are tested when we build from git, but not
when we build from a tarball release.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
Some test-cases in the dbus-daemon and relay tests spam the bus with
thousands of messages, which can take 25 seconds on slower CPUs like
MIPS. Similarly, the refs test spams millions of refcount operations,
which it appears might take more than a minute on PA-RISC (HPPA).
To get an idea of how close we are to having a problem on other
architectures, log a message and start a timer when we reset the
timeout in setup(), and log the elapsed time when we reach teardown().
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103009
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
We can't use normal I/O in a signal handler, so resort to write().
"Bail out!" is a special syntactic token in TAP. If I artifically force
the tests to time out by reducing timeouts and increasing the number of
operations, I get results like this:
ERROR: test-sd-activation - Bail out! Test timed out (GLib main loop timeout callback reached)
ERROR: test-refs - Bail out! Test timed out (SIGALRM received)
which is a lot easier to understand than "Not enough tests run" or
"nonzero exit status". The differing output is because test-sd-activation
iterates the main loop, whereas test-refs just blocks (it is joining a
series of worker threads, each of which is spamming refcount operations).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103009
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Use STDOUT_FILENO as per Philip's review]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is just enough to demonstrate that they work - I'm deliberately
not doing a mass change throughout all tests, and we should definitely
not rush to introduce these into production code, because it would
hinder cherry-picking and merging fixes between branches. However,
new code on master can use them freely.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101895
This lets cooperating processes with the same value of $HOME
interoperate for DBUS_COOKIE_SHA1 by reading and writing $HOME, even
if their $HOME differs from the uid's "official" home directory
according to getpwuid(). Out of paranoia, we only do this if the uid
and the euid are equal, since if they were unequal the correct thing
to do would be ambiguous.
In particular, Debian autobuilders run as a user whose "official"
home directory in /etc/passwd is "/nonexistent", as a mechanism to
detect non-deterministic build processes that rely on the contents of
the home directory. Until now, this meant we couldn't run dbus'
build-time tests, because every test that used DBUS_COOKIE_SHA1 would
fail in this environment.
In the tests, set HOME as well as DBUS_TEST_HOMEDIR. We keep
DBUS_TEST_HOMEDIR too, because Windows doesn't use HOME, only HOMEDRIVE
and HOMEPATH.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101960
Bug-Debian: https://bugs.debian.org/630152
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This test-case is actually in the test for monitoring the bus,
because it's easier to see what's going on there - the error reply
to a rejected broadcast is not visible unless you are monitoring.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853
Until the previous commit, this would have worked. Now it correctly fails
with "send and receive attributes cannot be combined".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853
configure.ac will detect PYTHON=python3 if there is no python
executable in the PATH.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101716
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
It is too easy for a developer working in an environment that has a
session bus to write tests that pass locally, but fail in minimal
environments. This is also risky because the tests might do
destructive things on the developer's real session bus. We can avoid
connecting to the session bus by consistently removing its address
from the environment, and replacing it with something that will
always fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101698
When we intend to exercise the default behaviour in the absence of
DBUS_SESSION_BUS_ADDRESS (but with an XDG_RUNTIME_DIR present), it would
help if we unset DBUS_SESSION_BUS_ADDRESS. Otherwise we'll just connect
to the real session bus, if there is one.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101698
test-pending-call-disconnected relies on being run under a session bus.
On master, the TESTS in this directory all get that treatment, but
in dbus-1.10 they do not. This caused test-pending-call-disconnected
to fail in minimal environments like travis-ci where there is no
developer-initiated session bus.
Backport part of commit ec6b220 "name-test: run most C tests directly,
not via run-test.sh" to wrap it in dbus-run-session. This is better
than putting it in run-test.sh because this way, its TAP output is
parsed directly by Automake.
It also has the side benefit of exercising dbus-run-session in the
automated tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101698
This lets _dbus_warn() and _dbus_warn_check_failed() fall through
to flushing stderr and calling _dbus_abort(), meaning that failed
checks and warnings can result in a core dump as intended.
By renaming the FATAL severity to ERROR, we ensure that any code
contributions that assumed the old semantics will fail to compile.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101568
When we listen on a tcp: address we should get a connectable tcp:
address, and so on.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101567
dbus_server_get_address() returns a copy. It isn't clear why.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101567
The error message was leaked when blocking on a pending call after
the connection was disconnected.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: re-word commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
The error message was leaked when blocking on a pending call after
the connection was disconnected.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: re-word commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
According to git history, this test was written in 2006 by Red Hat
employee John Palmieri and has received only trivial changes since
then. Red Hat gave permission in 2007 for their contributions to
be relicensed under the MIT/X11 license. We cannot take advantage
of that permission to relicense the core library or the dbus-daemon
from GPL-2+|AFL-2.0 to MIT/X11, because one early copyright holder
(CodeFactory AB) could not be traced, but we might as well use a
permissive license for simple test code that has not had
CodeFactory AB contributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
This re-executes the same binary with special command-line options
instead of forking. As a result, it can work on Windows, and is less
dependent on Unix libraries continuing to work across a fork().
(This has been confirmed to work in Windows binaries running under Wine.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101362
