The parameters to the test_pending_call_store_reply() call should match
those to the dbus_pending_call_set_notify() immediately after.
Coverity ID: 141876
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99999
Reviewed-by: Simon McVittie <smcv@collabora.com>
With this support cmake and autotools generates cmake equivalent of
pkgconfig files on configure time named DBus1Config*.cmake. These
files are installed into the related directory where cmake expects
find_package related config files.
For instructions how to use this feature with clients see readme.cmake.
With previous DBus versions each cmake client using DBus as dependency
needed a related FindDBus*.cmake in its source distribution or in
the cmake binary packages. With the 'config' find package style support
provided by this patch this requirement has been removed.
The generated config file uses pkgconfig on unix or autotools to
fetch package build flags, which is the prefered way. On Windows
we do not want to require CMake users to have pkg-config installed
so it uses cmake buildin target export support for exporting all
targets into DBus1ConfigTargets*.cmake.
[smcv: make sure variable substitution works in Autotools too]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Relocatable pkgconfig files are necessary when using packages installed to
a location that does not match the location for which they were compiled.
However, using ${pcfiledir} is problematic for system installations
in standard locations, because it interferes with pkg-config's
ability to filter out -I, -L options that are redundant with compiler
defaults (which is important if you are trying to use a newer version
of a library than the system copy).
In practice operating system vendors installing dbus to standard
locations use Autotools, so we enable relocatable builds by default
when building with CMake.
For simplicity, we're also not relocatable if the library directory
is something more complicated than lib or lib64 (e.g. under Debian
multiarch); we don't want to have to compute how many ../ to add.
This is non-trivial to determine in an Autotools build, so for now
there is no support for relocation when built with Autotools,
even as an opt-in feature.
Going via the ${original_prefix} variable is because under Autotools,
both ${prefix} and ${exec_prefix} technically default to NONE, with
NONE replaced with their real defaults of /usr/local and '${prefix}'
(respectively) later on. If we tried to expand ${prefix} at the time
that we choose the value of ${pkgconfig_prefix}, that would cause
a broken value "prefix=NONE" to be hard-coded.
[smcv: no relocation on Autotools, make it optional in CMake,
expand commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
The documentation generally only mentioned the directory in /etc, even
though we actually prefer security policies to be installed in
/usr/share to allow for stateless and volatile systems (i.e. booting up
with an empty /etc).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99901
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This should be a no-op, but it shuts Valgrind up.
The reason for the warning is that we fill in event.events and
event.data.fd, but the union event.data actually contains more bytes
than that. We'll get the same partially initialized union back from the
kernel in socket_set_epoll_poll(), where we take events[i].data.fd and
ignore the rest. So the current code is safe, but valgrind is right to
worry.
This is an expanded version of an older patch by Simon McVittie.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88808
Signed-off-by: Simon McVittie <smcv@debian.org>
Because this is in a subdirectory, it requires some extra `mkdir -p`
and some `nobase_` variables. Make all the installed-tests `nobase_`
for consistency.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Andre Moreira Magalhaes <andre.magalhaes@collabora.co.uk>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
For Unix, this partially duplicates the D-Bus Specification, but
provides more detail about the intention of each search path element.
It also documents the non-standardized path elements searched by the
reference implementation.
For Windows, there are no standardized path elements in the D-Bus
Specification (and it isn't clear how useful it would be to standardize
them, since Windows software that uses D-Bus tends to be installed
as an integrated "stack" with a bundled copy of a suitable dbus-daemon),
so we just document what the reference implementation does.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: fix formatting nitpicks]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We're treating transient services as higher-priority than those in
the XDG_DATA_HOME or XDG_DATA_DIRS, which is consistent with systemd.
The specific list used by the standard session dbus-daemon will be
added to dbus-daemon(1) in the next commit.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
To do this, we have to use the <standard_session_servicedirs/>.
A previous commit ensured that those don't provide any service files
we don't expect.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
For configuration purposes these are treated as part of the standard
session service directories, to avoid having to add new configuration
syntax which would prevent an old dbus-daemon from reloading
successfully. From an API perspective, they're separate, though.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
These directories can be used by service managers like `systemd --user`
and its generators, or by session infrastructure like gnome-session,
to synthesize D-Bus service files at runtime from some more canonical
source of information.
The intention is that this is in the XDG_RUNTIME_DIR as defined by the
freedesktop.org Base Directory Specification, which is private to the
user, and has a lifetime equal to the union of all the user's concurrent
login sessions.
This directory is provided on Linux systems that have systemd-logind and
pam_systemd, on other systems with PAM that have pam-xdg-support (which
has been abandoned by Ubuntu in favour of logind, but could be forked
by non-systemd environments that are interested in this functionality),
or any compatible reimplementation.
In practice this is most likely to be useful on systems that run
`dbus-daemon --session` from `systemd --user`.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is done on a per-directory basis.
The use of the BusContext here means we have to make the activation
test a little more realistic, by providing a non-NULL BusContext.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This lets us give them a flags word, which we immediately use to
track whether this directory should be watched with inotify or
equivalent.
The struct name is unfortunately a bit odd, because I had aimed to
use BusServiceDir, but activation.c already has BusServiceDirectory
so that would have been too confusing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
I'm about to change the version in the full-fat parser to return
BusServiceDir structs. Name this one with "paths" instead, to avoid
confusion.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This means we can test it more easily. At the moment it just
contains service directories, because this config file is so
cut-down that it doesn't have any config.d directories.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Otherwise, removing transient service directories that are being
watched by the dbus-daemon can fail with EAGAIN.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
daemon_pid will still be 0 if any tests were skipped. In particular
this happens during `make installcheck`.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Don't just exercise _dbus_get_standard_session_servicedirs(), but
also its integration into the BusConfigParser.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We can rely on the Autotools build system to pass in some safe values
for XDG_DATA_HOME and XDG_DATA_DIRS that match DBUS_TEST_BUILDDIR.
This test will now be skipped when running test-bus manually,
or under the CMake build system. Under CMake it could be reinstated
by setting the right environment variables.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: add missing newline as requested]
[smcv: align DBUS_TEST_BUILDDIR with G_TEST_BUILDDIR]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There's little point in asserting that the defaults (without
setting XDG_DATA_HOME, etc.) end with share/dbus-1/services,
because we are about to re-test with known values for XDG_DATA_HOME
etc., at which point we can check exact values which is more strict.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
progs was never used, because it was originally only used on
Windows, where this test makes no sense and so is no longer run.
It is unnecessary to check that the system service directories end
with dbus-1/system-services, because we are going to check their
exact values a short time later anyway.
It is also unnecessary to set XDG_DATA_HOME and XDG_DATA_DIRS,
because those variables are no longer respected for system service
directories, only for session service directories.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We want to be able to use <standard_system_datadirs/> in tests
without picking up someone else's .service files.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
There are two circumstances in which we load .service files. The first
is bus_activation_reload(), which is given an ordered list of directory
paths, and reads each one in its correct order, highest-precedence
first (normally ~/.local/share > /usr/local/share > /usr/share). This
seems correct.
However, if we are asked to activate a service for which we do not know
of a .service file, we opportunistically reload the search path and
try again, in the hope that it was recently-installed and not yet
discovered by inotify. Prior to this commit, this would iterate through
the hash table in arbitrary hash order, so we might load a service
from /usr/share even though it was meant to be masked by a
higher-priority service file in ~/.local/share or /usr/local/share.
Before I add more elements to the search path, we should make sure
it is always searched in the expected order.
We do not actually make use of the hash table's faster-than-O(n)
lookup by directory path anywhere, so there is no point in using a
hash table, and we can safely replace it with an ordered data structure.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is going to be necessary to be able to influence setup() and
teardown() as well as just the individual tests.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: also correct the same thing for system service directories]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We had two ways to append a path to the list of service directories.
Collapse them into one.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
There's no particular reason to be using a temporary directory (it's
just some arbitrary string), and it will be harder for future changes
to eradicate uses of a temporary directory that is shared between users
if we list it here.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99828
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Directories can't usefully appear in CLEANFILES, we have to delete
them recursively in clean-local.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99828
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This includes fixing a memory leak in _dbus_hash_iter_lookup(), which is
not one of the unit tests; but it is only ever called from the unit
tests, so this is not a user-facing leak.
Coverity IDs: 54730, 54740
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99793
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Creating a directory is atomic, stat'ing it to see whether to remove
it is very much not.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99828
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
If we don't trap EEXIST and its Windows equivalent, we are unable to
detect the situation where we create an ostensibly unique
subdirectory in a shared /tmp, but an attacker has already created it.
This affects dbus-nonce (the nonce-tcp transport) and the activation
reload test.
Add a new _dbus_ensure_directory() for the one case where we want it to
succeed even on EEXIST: the DBUS_COOKIE_SHA1 keyring, which we know
we are creating in our own trusted "official" $HOME. In the new
transient service support on Bug #99825, ensure_owned_directory()
would need the same treatment.
We are not treating this as a serious security problem, because the
nonce-tcp transport is rarely enabled on Unix and there are multiple
mitigations.
The nonce-tcp transport creates a new unique file with O_EXCL and 0600
(private to user) permissions, then overwrites the requested filename
via atomic-overwrite, so the worst that could happen there is that an
attacker could place a symbolic link matching the name of a directory
we are going to create, causing a dbus-daemon configured for nonce-tcp
to traverse the symlink and atomically overwrite a file named "nonce"
in a directory of the attacker's choice, with new random contents that
are not known to the attacker. This seems unlikely to be exploitable
for anything worse than denial of service in practice. In mainline
Linux since 3.6, this attack is also defeated by the
fs.protected_symlinks sysctl, which many distributions enable by default.
The activation reload test suffers from a classic symlink attack
due to time-of-check/time-of-use errors in its implementation, but as
part of the developer-only "embedded tests" that are only intended
to be run on a trusted machine, it is not treated as security-sensitive.
That code path will be fixed in a subsequent commit.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99828
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Hopefully this has better uptime than snapshot.debian.org, which is
really an archival service rather than a production component.
This particular autoconf-archive version was in Ubuntu 16.10, so it
should stay around for a while.
Signed-off-by: Simon McVittie <smcv@debian.org>
(cherry picked from commit 9935a5b7d1)
Odd that this one was missing but all the other ones were in place.
Coverity ID: 54721
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99724
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This reverts commit 5f0cd1a24c,
which appears to trigger a timeout:
dbus-daemon[26876]: Activating service name='org.freedesktop.DBus.TestSuiteEchoService' requested by ':1.2415' (uid=1000 pid=26876 comm=".../bus/.libs/test-bus ")
dbus-daemon[26876]: Failed to activate service 'org.freedesktop.DBus.TestSuiteEchoService': timed out (service_start_timeout=25000ms)
dbus-daemon[26876]: Did not expect error org.freedesktop.DBus.Error.TimedOut
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Hopefully this has better uptime than snapshot.debian.org, which is
really an archival service rather than a production component.
This particular autoconf-archive version was in Ubuntu 16.10, so it
should stay around for a while.
Signed-off-by: Simon McVittie <smcv@debian.org>
