Previously, 64-bit (LP64 or LLP64) platforms would have had 32 bits
of padding between pad2 and pad3. We want to guarantee that an ISO C
compiler will copy the entire struct when assigning between structs,
but padding is not guaranteed to be copied, so we want to ensure that
the struct is "packed".
Statically assert that the old ABI is compatible with the new ABI.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[smcv: change >= to == as Thiago requested]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
We already asserted that DBusMessageIter must be at least as large
as DBusMessageRealIter (so that casting DBusMessageIter * to
DBusMessageRealIter * does not result in overflowing the stack
variable). Also assert that it must have alignment requirements at
least as strict as those of DBusMessageRealIter * (so that casting
does not increase the required alignment).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
This is useful when making static assertions about our types'
properties.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
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>
