Otherwise, the tests try to connect to the real system bus, which will
often fail - particularly if you run the tests configured for the default
/usr/local (with no intention of installing the result), in which case
the tests would try to connect to /usr/local/var/run/dbus/system_bus_socket.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=52202
The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.
Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.
Fix this by hardcoding the starter address to the default system bus
address.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Colin Walters <walters@verbum.org>
On Unix, the connect address should basically always be "autolaunch:"
but the listen address has to be something you can listen on.
On Windows, you can listen on "autolaunch:" or
"autolaunch:scope=*install-path", for instance, and the dbus-daemon is
involved in the auto-launching process.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>
[default address changed to autolaunch: for interop with GDBus -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
This means the bus test can use them without needing
dbus-message-private.h, reducing its view of message internals.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
This makes it a bit clearer what's going on.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
When used with init systems such as systemd (where PID files are
redundant) this allows us to disable PID files even if a path is
configured for them in the normal bus configuration files.
Make use of this new switch in the systemd unit file.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45520
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In practice, it never works, because the activation helper doesn't
respect environment variables for security reasons.
If you want to vary the search path, alter system.conf instead, to
replace or augment <standard_system_servicedirs/> with your preferred
search path.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21620
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
To optimize startup a bit, drop machine UUID generation from the unit
file. Since a while D-Bus was already capable of making use of the
/etc/machine-id file, which is guaranteed to exist on systemd systems
(since the first released versions already), hence there's no need to
ever generate a D-Bus specific machine ID.
In times where userspace takes < 800ms to boot up getting rid of this
process optimizes boot time further.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45520
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Someone seems to have merged part of master into 1.4. Again. Let's go
back to the "last known good" point (the branch-point of some 1.4
branches I had locally), then we can cherry-pick the changes that
should have gone in.
In Unix, the tests listened on both debug-pipe (which is a socketpair,
or a TCP emulation of socketpair on Windows) and a Unix socket.
In the Windows port, the tests were hard-coded to listen on a particular
port, which allowed the dispatch test to connect to that port, as long
as no two tests ran simultaneously (which I don't think was ever guaranteed -
make -j can violate this). That's valid out-of-process, and also
fully-specified, so they only needed one <listen> directive, so the
CMake input only had one.
To make the tests work under CMake on Unix, there was a hack: the string
substituted for the content of the <listen> directive contained
</listen><listen> to get the other address in, which is pretty nasty.
Instead of doing that, I've made both build systems, on both Unix and
Windows, use both debug-pipe and a more normal transport (Unix or TCP).
debug-pipe has a Windows implementation and it's used in
dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
hard-coded rather than being a configure parameter (there's no reason
to vary it in different builds), and I used TEST_LISTEN as the name of the
Unix/TCP address, because it's a "vague" address (no specific Unix path, no
TCP port), that you can listen on but not connect to.
This in turn means that we can merge the Autoconf .in and CMake .cmake
files, similar to Bug #41033.
You might wonder why I've kept debug-pipe. I did try to get rid of it, but
it turns out that the tests in dispatch.c rely on
dbus_connection_open_private() not blocking, and normal socket
connections block on connect(). Until we fix that by adding an async
version of dbus_connection_open_private(), it won't be safe to have a
test like dispatch.c that "talks to itself", unless it uses a transport
as trivial as debug-pipe in which neither end has to block on the other.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
Since 1.4.4 (commit 75cfd97f) this function always returned FALSE. As far
as I can see this was actually harmless, because both of its callers
ignore any error that is not NoMemory (and treat it the same as success).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
If we're going to return FALSE for this (which has apparently always
been the case), then we should set an error properly.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
In commit ab7b3f9, Ralf notes that handle_reload_watch() is (in principle)
cross-platform. However, there's no way to trigger it on Windows, because
nothing ever writes to the pipe. Make the entire pipe-to-self trick
Unix-specific instead.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40002
This patch ensures the daemon process doesn't inherit any supplemental
groups for the root user from an administrator login via an init
script.
This is only an issue for pre-systemd systems.
https://bugzilla.redhat.com/show_bug.cgi?id=726953
On OSs with abstract sockets, this is close enough. On OSs without
abstract sockets, this results in failing to clean up Unix sockets
in /tmp if someone has sent us thousands of SIGHUP signals since we
last entered the main loop - I think that's acceptable.
The reload pipe should never get closed, but if it is for some reason,
we want a SIGTERM after that to cause an exit too.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38656
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
