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>
Some CI systems do the build as root in a disposable container, and
run tests without ever having installed dbus. This means we can't
expect to be able to drop privileges from root to the DBUS_USER (usually
named messagebus or dbus) unless we have checked that the
DBUS_USER exists.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This adds tests for mostly "send_destination_prefix" cases
and some "send_destination" cases.
The general test case is:
- addressed recipient is running and owns a name;
- a message is sent to the name owner;
- the response is checked for allow/deny (method return/error).
Each test case is executed both for primary and queued ownership.
The tests include:
- checking send allow/deny for names and namespaces, including nesting;
- checking send allow/deny for neighbour names;
- checking send allow/deny for names/namespaces+interface+member.
Signed-off-by: Adrian Szyndela <adrian.s@samsung.com>
Change-Id: If5fcada01601355e7aadefadad79c0b24f8c397f
In D-Bus I'd expect "ay_iter" to be an iterator over the type 'ay',
i.e. a byte-array. Abbreviate a little less to avoid this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Traditional activation could be disabled if all services use
SystemdService activation instead. Provide an example of a hardened
DBus systemd service drop-in file for such a setup.
Signed-off-by: Topi Miettinen <toiwoton@gmail.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
This simplifies bootstrapping: now you don't have to build dbus,
build dbus-python (with GLib), and use dbus-python to test dbus.
It also avoids test failures when using facilities like
AddressSanitizer. When libdbus is built with AddressSanitizer, but the
system copies of Python and dbus-python were not, dbus-python will exit
the Python interpreter on load, because libasan wasn't already
initialized. The simplest way to avoid this is to not use Python:
the scripts are not *that* hard to translate into C.
Both of these tests happen to be conditionally compiled for Unix only.
test_activation_forking() relies on code in TestSuiteForkingEchoService
that calls fork(), which can only work on Unix; meanwhile,
test_system_signals() tests the system bus configuration, which is
only relevant to Unix because we don't support using dbus-daemon as
a privilege boundary on Windows (and in any case D-Bus is not a Windows
OS feature, so the system bus cannot be used to communicate with OS
services like it can on most Linux systems).
This is also a partial solution to
<https://gitlab.freedesktop.org/dbus/dbus/issues/135>, by reducing the
size of name-test/.
For this to work, we need to build the test-service helper executable
even if embedded tests are disabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The implementation of the max-connections-per-user limit works in terms
of Unix uids, so it doesn't apply on Windows.
This is not a problem in practice, because it only makes sense to limit
connections per user if you have multiple users, and we don't support
the well-known system bus on Windows.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
We don't need to do this for connections that were never set up
with the main loop.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
Not all of these tests will be fully valgrind-clean yet (or perhaps
ever), but it's easier to add this to all of them than to think
about it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
In gcc 8, -Wall -Wextra includes -Wcast-function-type, which warns
about passing an extra (unwanted) parameter to callbacks. Instead
of using g_list_foreach(), open-code the equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Reviewed-by: Thiago Macieira <thiago@kde.org>
These connections are not to a container server.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
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>
test_object_try_whatever() now has libdbus-like OOM handling,
while test_object_whatever() has GLib-like OOM handling. This is
because an overwhelming majority of the callers of these functions
either didn't check for OOM anyway, or checked for it but then
aborted. In the uncommon case where we do care, we can use the _try_
version.
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>
Also use test_oom() where the relevant lines are changing anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
It seemed like a nice idea at the time, but I now think it's more
confusing than it's worth.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
Previously, we allocated m both during initialization, and after
deciding not to skip this test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
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>
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
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
We have to skip the GetMachineId() part during build-time testing
if it wouldn't work - there is no guarantee that dbus has ever been
installed on the build system. However, we can insist on it during
installed-tests, if we make sure to complete the installation for the
Travis-CI build by running dbus-uuidgen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101257
The GLib functions we're using don't, and it seems to be possible to be
interrupted during cleanup for our tests.
Windows apparently has and uses ENOENT for _unlink(), so just do the
same on Windows there; but EINTR is very much a POSIX thing, so ignore
that on Windows.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: add Windows fixes from a later commit, also reviewed by Philip]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is a workaround for
<https://bugs.freedesktop.org/show_bug.cgi?id=95263>. If a service
sends a file descriptor sufficiently frequently that its queue of
messages never goes down to 0 fds pending, then it will eventually be
disconnected. logind is one such service.
We do not currently have a good solution for this: the proposed
patches either don't work, or reintroduce a denial of service
security vulnerability (CVE-2014-3637). Neither seems desirable.
However, we can avoid the worst symptoms by trusting uid 0 not to be
malicious.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1591411
Reviewed-by: Łukasz Zemczak
Tested-by: Ivan Kozik
Tested-by: Finn Herpich
Tested-by: autostatic
Tested-by: Ben Parafina
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This makes life easier for frameworks like LAVA that screen-scrape
test results.
g_test_message() is not displayed by default, but each test can be run
with either --tap or --verbose to get these messages displayed.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89846
