On a whitelist of OSs known to have working credentials-passing
(currently FreeBSD, Linux, OpenBSD and NetBSD), it would be a
regression for us to not have credentials-passing, so fail hard.
On other OSs, raise a warning, which is not normally fatal but
will alert developers on those platforms.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60340
Reviewed-by: Colin Walters <walters@verbum.org>
It appears that this regressed back in 2009 (commit 7bf132c7)
and doesn't compile. Also, with patches from Matt Fischer to make
it compile again on QNX, it compiles but doesn't actually work
on NetBSD, which was the platform for which this code was added.
This might be for the reasons described in
<http://julipedia.meroh.net/2006/08/localcreds-socket-credentials.html>.
NetBSD pkgsrc has a large unsubmitted patch to use LOCAL_PEEREID, which
is analogous to Linux/OpenBSD SO_PEERCRED.
So, I think we can safely assume that nobody is relying on this:
either they implement one of our many other supported
credentials-passing mechanisms, or they're patching it locally
anyway.
LOCAL_CREDS is not actually very good - it's awkward to use, and
doesn't provide the pid, only the uid. Of the platforms known to
implement it, QNX and NetBSD both have getpeereid() which provides
just as much information, while FreeBSD and Dragonfly BSD both have
SCM_CREDS which provides the pid too. So, let's just get rid of it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60340
Reviewed-by: Colin Walters <walters@verbum.org>
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This has been a soft requirement since 1.5.0; anyone on such platforms
would have had to configure --without-64-bit, provoking a warning that
instructed them to report a D-Bus bug with details of their platform.
Nobody has done so, so if anyone still lacks a 64-bit integer type,
they're on their own.
(Also, I tried the build with --without-64-bit and it's full of
fatal compiler warnings, so it's not clear that we're actually
losing anything by removing this "feature".)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This block provoked a warning on mingw-w64 because we were redefining
_inline. According to Ralf's research, it was introduced in 452ff68a:
Windows 2000 doesn't have getaddrinfo and related functions in
ws2tcpip.h, but does have a shim implementation in wspiapi.h.
At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
why there was a __GNUC__ code path here. The "#define _inline" on that
code path looks likely to be some sort of workaround for a faulty version
of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
__GNUC__ code path and get the redefinition.
dbus no longer supports Windows 2000, so we no longer need wspiapi.h
at all, and can rely on XP or later. (Ralf's policy is to only support
versions of Windows that are still supported by Microsoft, and Windows 2000
reached the end of its life-cycle in 2010.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker
The disable-userdb-cache code path is never been fine tested and you
could expect an extramely slow bus if you did that. And there are known
bugs on fd.o if build without userdb cache. So to prevent user from
using bus without userdb cache, it changed to a built-in feature, no
longer optional now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66947
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=15589
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In practice, it won't; other forms of autolaunch (like Mac OS launchd)
might, but we can't really assert either way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40352
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[amended to reinstate use of dbus/dbus-sysdeps.h which was removed
by 412538b3b9 -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
When we drop capabilities we shouldn't assume we can keep
CAP_AUDIT_WRITE unconditionally, since it will not be available when
running in containers.
This patch only adds CAP_AUDIT_WRITE to the list of caps we keep if we
actually have it in the first place.
This makes audit/selinux enabled D-Bus work in a Linux container.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49062
Acked-by: Thiago Macieira <thiago@kde.org>
Acked-by: Colin Walters <walters@verbum.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
According to Wikipedia
http://en.wikipedia.org/wiki/Latency_%28engineering%29#Packet-switched_networks
latency means "the time from the source sending a packet to the destination
receiving it". Therefore, latency is unrelated to whether the operation is
asynchronous or synchronous. And also unrelated to whether it's one-way or
round-trip. Latency exists for asynchronous and one-way transfer, because for
current DBus implementations we need at least one context switch to transfer
each message from the sender process to the receiver process. Emphasizing
D-Bus is low-latency could encourage user to abuse/misuse the system.
Mail disscusion:
http://lists.freedesktop.org/archives/dbus/2013-May/015665.html
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65141
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In dbus-daemon implementation, the servicedir are searched in order in
which they appear in the config file.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66994
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_COMPILATION definition was moved to test/Makefile.am static_cppflags,
so remove it from test source code.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It was reported that accept4() will return -1 with errrno is EINVAL on
arm platform, so check EINVAL for accept4() and retry accept().
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69026
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If SOCK_CLOEXEC is defined (usually because accept4 is implemented),
check for EPROTOTYPE (the POSIX errno for invalid socket types) in
addition to EINVAL as errno indicating whether socket and socketpair
do not support SOCK_CLOEXEC (and other SOCK_* flags).
[adapted by Chengwei Yang to give _dbus_connect_exec() the same treatment]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69073
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As the same as _dbus_open_socket() and _dbus_full_duplex_pipe(),
socketpair() may fail with EINVAL if call with SOCK_CLOEXEC.
Check for the failure and retry without SOCK_CLOEXEC, in addition, only
call _dbus_fd_set_close_on_exec() if the socketpair failure happened.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69073
[trivial coding style fixes -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The function dbus_connection_set_route_peer_messages() take a bool
argument, however, in the implementation, it always hard-code to TRUE
rather than take its bool argument.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69165
[amended commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The last argument of function _dbus_transport_new_for_socket() is
declared as const DBusString *. However, it is passed as a bool value.
Although the value of FALSE equals NULL in fact, this is an incorrect
use of function.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69165
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix a file descriptor not being closed when an error codepath is taken.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69182
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[more specific commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If waitpid() failed with EINTR, we'd go back for another go, but
because ret is nonzero, we'd skip the waitpid() and just keep looping.
Also avoid an unnecessary "goto" in favour of a proper loop, to make it
more clearly correct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68945
Reviewed-by: Colin Walters <walters@verbum.org>
In a previous patch, it check SIGHUP for windows, however, in fact there
is dbus-launch-win.c supposed to be used on windows. So just use SIGHUP
unconditionally.
Also free memory on OOM, although this doesn't make much sense since
this is a oneshort program, rather than a daemon.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66068
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In theory the Autotools build system supports any "make" implementation,
but there are no regular contributors who test with BSD make, so the
inevitable result is that only GNU make actually works (fd.o #48277).
Apparently there's only one GNUism at the moment, which is fixable,
but that means repeating ourselves a bit more. If we instead document
that GNU make is required, we can simplify the Makefiles over time
by using extensions like $(patsubst), leading to a less error-prone
build system.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48277
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
