GitLab

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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825Reviewed-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=99825Reviewed-by: Philip Withnall <withnall@endlessm.com>
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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-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=99825Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <smcv@debian.org>

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=99828Signed-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=99828Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

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=99793Reviewed-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=99828Signed-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=99828Signed-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 9935a5b7)

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=99724Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This reverts commit 5f0cd1a2,
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>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721Reviewed-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>

This test is run repeatedly, with simulated out-of-memory conditions
at different points. If one of these was during run_decompose_tests(),
the test was recorded as failing. Before Philip fixed it, this was
masked by the failure not being reported correctly (CID: #54711).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99758Reviewed-by: Philip Withnall <withnall@endlessm.com>

Coverity ID: 54711
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99758Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>