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>
In principle we ought to define DBUS_STATIC_BUILD in anything that's
using libdbus-internal.la (to avoid linking failures on
statically-linked mingw builds), and DBUS_TEST_USE_INTERNAL in any
test that's using the non-dbus-glib code paths of test-utils.[ch]
(to avoid the GLib requirement, although in practice, everything
"shared if possible" requires GLib at the moment anyway).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
GSocket takes responsibility for closing the fd, and there doesn't
seem to be any way to tell it not to. When this test is adapted to run
under DBusLoop as an alternative to dbus-glib, that becomes a problem,
because DBusLoop/DBusSocketSetEpoll do not tolerate that. Work around it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This function is meaningless (and possibly unimplementable) on Windows.
We shouldn't call it; if we do, it should raise an error.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
On Windows, the dbus-daemon is not able to fork (daemonize). If someone
explicitly requests forking, it should fail, but if someone
explicitly requests *not* forking, there seems no harm in allowing it.
A few of the regression tests specifically require a dbus-daemon that
will not fork, so allowing this option on Windows means those tests
don't need an extra OS condition.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This means we don't need to worry about whether it's thread-safe,
and makes libdbus a little smaller.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This function could be accessed from any thread, which would mean it
scribbles on argv twice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
If we _dbus_verbose() from more than one thread at the same time,
we don't want to get into trouble with static variables (and I don't
think micro-optimizing this function is really worth it anyway).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This reverts commit 83aaa9f359.
This wasn't right: because it looked for a symbol from pthread.h,
modules could end up disagreeing about whether threading was enabled or
not.
Sharing a static variable between threads is not safe in general,
and this function is used in the shared libdbus (for nonce files),
so it can't rely on being single-threaded.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Assigning to libdbus_1_la_DEPENDENCIES defeats Automake's normal
dependency logic, which makes libdbus-1.la depend on all the
static libraries that will go into it (it still had a corrct dependency
on the other objects, which go through a separate variable).
This meant libdbus-init-win wasn't necessarily built first.
Use EXTRA_libdbus_1_la_DEPENDENCIES to avoid that problem.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68505
Acked-by: Ralf Habacker <ralf.habacker@freenet.de>
dbus_server_disconnect() invokes dbus_server_unref() at the end of
function, the latter will print a trace about server ref count decrease
1. However, it doesn't invoke dbus_server_ref(), so there isn't a trace
about server ref count increase in debug output.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68303
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
