The exception is test-autolaunch, which is really not particularly
useful as a build-time test. The only way we can really test
autolaunch is as a whole-system integration test, and "make check"
is not that.
The two tests written in Python and one test based on dbus-send
are also not run directly yet; in particular, that includes both
the tests in run-test-systemserver.sh.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Similar to commit 58eefa1031.
test-privserver is a helper executable, not a test. I moved its output
from stdout to stderr so it can't be misinterpreted as the test's
stdout.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93908
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: Re-enable the failing test that Nick disabled, and fix the
expected result; the result given by our current implementation is
reasonable.]
dbus-daemon is not expected to open files with large *sizes*, but without
large file support, calling [f]stat() on a file that happens to have a
large inode number will fail with EOVERFLOW (see stat(2)). For example,
files mounted from an NFS server might have large inode numbers.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93545
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
[smcv: shorten and clarify commit message; move AC_SYS_LARGEFILE
after AC_USE_SYSTEM_EXTENSIONS because nothing should compile C before
that point]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Since 1.10.4 this is hard-coded to be disallowed when an activation
helper is used. That would be a security flaw waiting to happen,
and makes little sense anyway, because the activation helper sanitises
its environment.
Use BecomeMonitor() instead, as our way to assert that root and
messagebus are privileged.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93036
Reviewed-by: Iain Lane
The wrapper shell script that sets up their environment is nowhere
near being portable. In particular, it uses dbus-run-session,
which is Unix-specific.
[rh: Add autotools scope in commit title]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Rewieved-by: Ralf Habacker <ralf.habacker@freenet.de>
Attempting to call SetEnvironment on systemd causes it to inquire
about the caller's connection UID and PID. If this check fails,
the call is rejected.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92857
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: go back to DBUS_ERROR_UNIX_PROCESS_ID_UNKNOWN as the error code
for failure to determine the pid]
If we use systemd activation, forward all UpdateActivationEnvironment
requests to org.freedesktop.systemd1.Manager.SetEnvironment, in order
to ensure variables needed by D-Bus services are available when these
services are launched by systemd.
Since UpdateActivationEnvironment is not available on the system bus,
this only applies to user buses.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92857
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The default policy already disallows calls on system buses. Since any
bus with a service helper cleans the environment anyway, there's no
point in allowing this to be called.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92857
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As well as slightly increasing our test coverage, this ensures
that at least one test-case in this test is not skipped, working
around CMake's lack of support for the Automake-style exit code
produced by GTest executables (they exit 77 if everything was skipped).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92887
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Backtrace generator called _dbus_warn(), which calls
backtrace generator recursively with DBUS_FATAL_WARNINGS=1.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Because GetConnectionUnixUser is not supported on windows it fails with
DBUS_ERROR_FAIL.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The system bus is unsupported there and Windows does not
have any concept of setuid binaries, so it can't ever
actually work.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There is no need to make a local (leaked) copy of the message,
because dbus_set_error() already makes a copy of its parameters.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Windows returns unhandled exceptions from a running child
by specific exit codes and not by signals as on UNIX.
Therefore we use DBUS_ERROR_SPAWN_CHILD_EXITED for propagating
unhandled exceptions to the parent too.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBus test cases running the server *and* client loop in the same
process assumed that all messages send from the server has to be
received in one client dispatch, which is not the case in all
environments.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Only set valid child status in case exit code has been gotten from
child process, otherwise signal failure through thread return value.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, we didn't consistently test parsing of every file in
valid-config-files-system/ everywhere that we tested valid-config-files/.
We now test it on Unix.
The system bus is not supported on Windows, so we do not test
valid-config-files-system/ there.
valid-config-files/many-rules.conf contains <user> and <group> rules
which are not applicable to Windows. Copy the original many-rules.conf
to valid-config-files-system/ so that it will be tested on Unix, and
remove the non-portable rules from valid-config-files/many-rules.conf.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[rh:base patch came from Simon]
The tests are run with _dbus_warn() fatal, so if a particular test is
not applicable on the current platform, we shouldn't call it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
If D-Bus was configured for /usr/local and built in Z:/build,
the previous code would use
Z:/build/dbus/.libs/usr/local/share/dbus-1/services
whereas the intention was to replace the configured prefix /usr/local
with the detected location, more like
Z:/build/dbus/.libs/share/dbus-1/services
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Under Wine, the API calls we use to do this are implemented via IPC
to wineserver, which makes it unreasonably slow to try to brute-force
bugs by having many threads stress-test refcounting. Do a few
repetitions just to verify that refcounting basically works, but
don't do the full stress-test.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92538
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[rh: add WINESERVERSOCKET related hint]
If we're running Windows executables using Wine, then tap-driver.sh
won't accept "1..4\r\n" as TAP syntax.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92538
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
