This patch is based on the patch created by John (J5) Palmieri
<johnp@redhat.com> plus to fix array of string assignment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=13305
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Currently, DBus Specification only consists of four message types, so to
monitor all the types of message, no need to match all of them but just
left it empty is OK.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66107
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We assume that user/developer who building dbus from source code are
familiar with the standard 'autogen.sh, configure, make, make install'
build process, so print such a notice doesn't make a lot of sense.
In addition, on *BSD platform, the pre-installed 'make' doesn't work at
all since gnu make is required. However, it named to 'gmake' on *BSD
platform. So the notice will makes new comer confused.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65415
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is the configuration I'd like to use for the "debug build" of dbus
on Debian - if we use --with-valgrind=yes, we have to hard-code knowledge
of which architectures do and don't have Valgrind in two places instead
of just one.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=56925
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
There are two build failure on NetBSD 6.1.1 with gcc 4.5.3, the first
one is char to int, warning treated as error. The second one is a mismatch
between format string and arguments.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69842
[adjusted commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Neither '-a' nor '-v' of 'cp' is available on OpenBSD 5.3, so use 'cp'
instead to fix portable issue.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69789
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
chmod -c is not available on *BSD system, and '-v' is not available on
OpenBSD, so just execute chmod without any option.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35881
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
