From git history, enable_x11 was used to track have_x11, but it's
useless now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65443
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[The libxml code path has been broken for at least 2.5 years, and Expat
is tiny, so there seems no point in supporting both. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=20253
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As Ralf pointed out, we usually use upper-case when substituting
variables (apart from "somethingdir", which Autoconf conventionally
makes lower-case for some reason).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63682
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
QNX has an arbitrary limit to the number of file descriptors
which may be passed in a message, which is smaller than the
current default. This patch therefore changes the default from
a hardcoded constant to a macro, which is determined at configure
time by looking at the host operating system.
[This reduces the limit from 4096 (session)/1024 (system) to 128 fds
per message on QNX, and 1024 fds per message on other operating systems.
I think the reduced session bus limit on other OSs is a reasonable change
too, given that the default hard/soft ulimits in Linux are only 4096/1024
fds per process. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
Reviewed-by: Simon McVittie <simon.mcvittie.collabora.co.uk>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
This function is called by _dbus_read_credentials_socket() to fetch client credentials.
Because Wine is used to check cross compiled dbus for windows, in calls to GetExtendedTcpTable()
we use table class TCP_TABLE_OWNER_PID_ALL instead of TCP_TABLE_OWNER_PID_CONNECTIONS.
This class is the only one which is available since wine 1.5.3.
https://bugs.freedesktop.org/show_bug.cgi?id=61787
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
This means we no longer need man2html, which is nice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In principle, anything in the pthread namespace might either be in the
platform-specific thread library (libpthread or libpthreads or libthreads
or ...), or in libc.
In particular, it seems that pthread_mutexattr_init and
pthread_mutexattr_settype are in libpthread, not libc, on Linux. We
previously didn't (intentionally) look for them in libpthread, only
in libc; so this check deserved to fail.
However, a faulty configure check for pthread_cond_timedwait
worked around this on Linux by checking for -lpthread and adding it
to THREAD_LIBS if pthread_cond_timedwait *was* found in libc (even
though that behaviour makes no sense).
The practical impact was that D-Bus would fail to compile on platforms
where pthread_cond_timedwait is in a special threading library that
is not linked by default, and at least one of
(pthread_mutexattr_init, pthread_mutexattr_settype) is also in a
special threading library. This is the case on at least OpenBSD
(fd.o #54416).
So far I've only added checks for the new symbols introduced by
using recursive pthreads mutexes. If we get reports of compilation
failures on weird platforms, we can check for more symbols.
Also clarify the indentation, which was turning into quite a mess,
and use AS_IF instead of if/elif/else/fi in accordance with Autoconf
best-practice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47239
Reviewed-by: Colin Walters <walters@verbum.org>
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>
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>
