[FreeBSD and OpenBSD contributors clarified that O_CLOEXEC has been
supported for ~ 2 years on both, so for the moment we're assuming
that every platform with kqueue also has working O_CLOEXEC. Please reopen
the bug, with a tested patch that uses _dbus_fd_set_close_on_exec() instead,
if this assumption turns out to be false. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72213
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There is a DBusList* member of BusTransaction named "connections", while
its getter function bus_transaction_get_connections() returns
context->connections which in fact is a BusConnections pointer, this is
quite confusing. Because this is what bus_context_get_connections()
returns.
This patch call out to bus_context_get_connections() directly and remove
the then unused bus_transaction_get_connections().
https://bugs.freedesktop.org/show_bug.cgi?id=71597
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are memory blocks leak when doing bus-test, both dispatch-sha1 and
dispatch test cases complain memory blocks leak.
This patch also fix fd leaks.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69332
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The message bus which can monitor its conf dirs for changes and reload
confs immediately if dir monitor enabled, for example, inotify in Linux,
kqueue in *BSD.
However, it doesn't apply policy rules change for completed connections,
so to apply policy rules change, the client connection has to disconnect
first and then re-connect to message bus.
For imcomplete connections, it always has the latest review of policy
rules.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39463
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previous to the introduction of selinux_set_mapping(), DBus pulled
constants generated from the system's policy at build time. But this
means it's impossible to replace the system policy without rebuilding
userspace components.
This patch maps from arbitrary class/perm indices used by D-Bus and
the policy values and handles all the translation at runtime on
avc_has_perm() calls.
Bug: https://bugs.freedesktop.org/attachment.cgi?id=88719
Reviewed-By: Colin Walters <walters@verbum.org>
Tested-By: Colin Walters <walters@verbum.org>
As soon as capng_clear() is called, we won't appear to have
CAP_AUDIT_WRITE. Fix this by checking for it before resetting the
libcap state.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49062
Tested-by: Laurent Bigonville <bigon@debian.org>
Reviewed-by: Laurent Bigonville <bigon@debian.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
DBusBabysitter->executable is defined as executable name to use in error
messages. However, if servicehelper used, then the executable name is
servicehelper. It's not much help because we couldn't figure out which
service we're trying to activated if error happens.
In the following patch, we'll use service name to be activated as the
child log identifier and add a parameter to
_dbus_spawn_async_with_babysitter() to pass the log identifier. Since
this is not the case in test, so executable changed to log_name.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68559
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Key-word "Group" of DBus .service file hasn't been used since it was
introduced in 2007, so it's fine to remove it.
https://bugs.freedesktop.org/show_bug.cgi?id=19158
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
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>
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>
At previous, it will do get pid and print a verbose string per inotify
event, and then do send signal to the daemon.
This patch changes the behavior to get pid and print a verbose string
one time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68303
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It's sufficiently portable that GLib has an equivalent, and I really
don't want to have to either open-code it in dbus-run-session or
link dbus-run-session statically. We have enough statically-linked
rubbish already.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Reviewed-by: Colin Walters <walters@verbum.org>
In order to authorize/reject a connection in a polite way, instead of
cutting it off after authentication succeed and Hello() is
sent, because authorization failed, we need to factor out some
authorization bits from DBusTransport and pass them to DBusAuth.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39720
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The initial set of credentials is just UnixUserID and ProcessID.
The rest can follow when someone is sufficiently interested to actually
test them.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54445
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[rename a function that Ralf found unclear -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
dnotify as a dir watch backend is broken since Jan 2010 (almost 3.5
years). According to fd.o: #33001, it's no harm to remove dnotify from
this project.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33001
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This lets them be thread-safe by default, at the cost that they can
now fail.
init_uninitialized_locks() and init_global_locks() must now both
reimplement the equivalent of _dbus_register_shutdown_func(), by using
_dbus_platform_rmutex_lock() on the same underlying mutex around a call
to _dbus_register_shutdown_func_unlocked().
This is because if they used the usual _DBUS_LOCK() API (as
_dbus_register_shutdown_func() does), it would automatically try to
initialize global locking, leading to infinite recursion.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Anas Nashif <anas.nashif@intel.com>
dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853
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>
dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.
In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.
In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.
In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.
In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@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>
This causes the test to fail. The assumption implicitly being made was
"if pid 1 is systemd, then every caller of _dbus_init_system_log() is a
systemd service" which is not valid for the regression test.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63163
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
