Building it unconditionally causes problems for minimal installations
(OSTree), and building it opportunistically means the tarball isn't
guaranteed to contain it, depending who releases libdbus and which
packages they happen to have installed at the time. If this documentation
is important enough that we need to ship it precompiled in tarballs,
we should guarantee it; or if it isn't important enough to justify that,
we should just drop it.
I don't think we really need it in the tarballs at all: most users
will get their libdbus from a binary distribution (in which case I expect
the distribution's dbus maintainers to set appropriate
build-dependencies), and those who build from source can either
install xmlto, read the documentation on our website, or at worst,
read the source XML. (We don't put the Doxygen-generated API reference
HTML in the tarball either, and I haven't heard any complaints.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55426
Reviewed-by: Colin Walters <walters@verbum.org>
The dup2() calls immediately afterwards will close the "destination" fd
if necessary.
[commit message added -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Quick documentation on how Valgrind can be run in clients without
triggering false positives.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55933
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Newer valgrind (tried with 3.8.0) defines macros so that a terminating
semi-colon is required. This fixes usage to follow that convention.
[edited to remove comments that are no longer useful -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55932
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
commit 90f939f155 had two problems.
1) a small whitespace error in the added comment
2) the wrong bug reference at the bottom
I'm using 1) as an excuse to add additional commit for the sake
of 2).
https://bugs.freedesktop.org/show_bug.cgi?id=56043
dbus's service activation code sets SIGPIPE to SIG_DFL as a
sort of poor man's prctl(... PR_SET_PDEATHSIG) to detect when
the parent goes away.
It neglects to reignore the infamous signal before performing
activation, however.
This means if, for instance, journald is restarted all
services activated after it will die with SIGPIPE when logging
messages unless they explicitly ignore SIGPIPE themselves.
This commit changes dbus's service activation code to correctly
ignore SIGPIPE to protect activated services from a gruesome,
premature death.
Reviewed-by: Lennart Poettering <lennart@poettering.net>
https://bugzilla.redhat.com/show_bug.cgi?id=839258
When dbus gets launched through systemd, we need to create an address
string based on the sockets passed.
The _dbus_append_addres_from_socket() function is responsible for
extracting the address information from the file-descriptor and
formatting it in a dbus friendly way.
This fixes bus activation when running dbus under a systemd session.
https://bugs.freedesktop.org/show_bug.cgi?id=50962
Signed-off-by: Simon Peeters <peeters.simon@gmail.com>
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>
This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).
In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.
https://bugs.freedesktop.org/show_bug.cgi?id=52202
This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.
https://bugs.freedesktop.org/show_bug.cgi?id=52202
This matches a corresponding change in GLib. See
glib/gutils.c:g_check_setuid().
Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
How to determine whether or not we're running in a privilege-escalated
path is operating system specific. Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
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>
This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).
In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.
https://bugs.freedesktop.org/show_bug.cgi?id=52202
This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.
https://bugs.freedesktop.org/show_bug.cgi?id=52202
This matches a corresponding change in GLib. See
glib/gutils.c:g_check_setuid().
Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
How to determine whether or not we're running in a privilege-escalated
path is operating system specific. Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-by: Sebastian Krahmer <krahmer@suse.de>
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>
The system bus is unsupported (and rather meaningless) on Windows anyway,
so we can use anything. Also, make it clear that it has to be a
"specific" address that can be listened on *and* connected to,
like unix:path=/xxx - a listen-only address like unix:tmpdir=/xxx or
nonce-tcp: would not be suitable.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>
