| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=56927
[commit message added -smcv]
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>
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
| |
Follow to reverting a556443757b19fee67ef4441141246dd9cfed4f.
See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24
This reverts commit d7ffad72146c2329692e0cf32eb1ac1dbb4fb51c.
|
|
|
|
|
|
|
|
| |
It breaks gnome-keyring-daemon at least in some
configurations; see
https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24
This reverts commit 1a556443757b19fee67ef4441141246dd9cfed4f.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
It's not really useful.
See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c17
|
|
|
|
|
|
|
|
|
|
|
| |
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 is a highly theoretical concern, but we might as well.
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 OpenBSD, sys/socket.h requires sys/types.h to be included first.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54418
|
|
|
|
| |
This reverts commit 05b0b9e65b6a58f0b0cb56d6ee8cf100061250b3.
|
|
|
|
|
|
|
|
| |
addresses and set better defaults"
This reverts commit b5d36dc27d1905d4d46ad7f0097f0ea0e0776adb.
On second thoughts, this is too big a change for a stable branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
set better defaults
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>
|
| |
|
|
|
|
|
|
| |
[smcv: comments updated, commit message added]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53286
|
|
|
|
|
|
|
|
| |
It's always defined.
[smcv: commit message added]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53286
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If dbus is installed in a path, which contains a space, dbus-launch will
not launch the daemon. That is so, because a command line is built from
just the path to the daemon and a parameter. The path has to be
surrounded with quotes. This can be done unconditionally, because the
quotes do not cause any trouble even if they are not needed.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49450
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Misplaced [] and () led to enable_developer=no being part of the
option's documentation instead of actually being the default value.
Regression in 1.6.2, caused by #34671.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51657
Bug-Debian: http://bugs.debian.org/680027
Reviewed-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
dbus-launch can apparently return an empty address under certain
circumstances, and dbus_parse_address() in the next line will return
a nice DBusError for an empty address rather than aborting the process.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51657
Bug-Debian: http://bugs.debian.org/680027
Reviewed-by: David Zeuthen <davidz@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
This removes the assumption that DBUS_CONSOLE_AUTH_DIR ends with a
trailing /.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51521
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
| |
|
| |
|
| |
|
|
|
|
| |
reverted
|
|
|
|
| |
This reverts commit fcc656d430f53ad62c25e41d7e7bd880cbb726a0.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Since Automake 1.11.4, an empty localstatelib_DATA variable will not
create $(localstatelibdir) as a side-effect.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51406
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51032
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
|
| |
|
|
|
|
|
|
|
|
| |
See http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/
for more information.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34671
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Automake maintainer mode isn't about whether you're a maintainer or not
(although its name would suggest that), it's about whether files that are
normally distributed in the tarball get regenerated. As such, it's
not really appropriate to use it to drive defaults for things like
assertions and extra test code.
The desired effect is that developers building from git normally get
tests and assertions, while distribution packagers don't.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34671
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
On Linux, this is libpthread; on other Unixes, in principle it might be
called libpthreads or libthreads or something.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47237
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.
Based on patches from 'william' on fd.o #46367.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33973
Tested-by: René Berber <Rene.Berber gmail com>
|
| |
|