Previously, if a method call activated a service, it would only be
delivered to that service, and not to other services with match rules
which should match. This patch replaces the improperly-duplicated
dispatch code in activation.c with a call back into the normal dispatch
code, fixing this bug (fd.o#26427).
(Additionally, were one to service-activate a service that doesn't
understand file descriptors with a message containing a file descriptor,
the previous code would send it anyway, and the service's dbus library
would blow up. This is also fixed here, since the normal dispatch code
checks this correctly.)
https://bugzilla.redhat.com/show_bug.cgi?id=572769
Previously we'd just continue if AVC initialization failed, but
that didn't really work because then we'd later crash in
avc_has_perm.
Simply treat initialization failures as fatal, and hopefully we
can get data from the system log.
Previously we were simply logging as "dbus", and it was unclear
whether it was the system bus, or a session bus. And if the latter,
which user?
This patch adds a prefix to the log message with the bus type
and the userid.
https://bugs.freedesktop.org/show_bug.cgi?id=23957
Previously we detected glibc support at compile time and used
it unconditionally; better to try it and fall back, this way
we continue to run on older kernels when compiled for newer ones.
It's not expected to have to manually SIGHUP the bus after installing
a new .service file. Since our directory monitoring is already set
up to queue a full reload which includes service activation, simply
monitor the servicedirs too.
https://bugs.freedesktop.org/show_bug.cgi?id=23846
Internal setup of session bus type was bound to the presence of the --session
command line parameter which prevents to use the --config-file parameter for
session bus setup.
We were incorrectly passing NULL for a DBusList when the usage expected
is a pointer to a NULL DBusList pointer. Also during dbus_shutdown
we need to actually close the inotify fd, and remove our watch.
Move the shutdown handler out of bus.c and into inotify where we
can do all of this cleanly.
(cherry picked from commit 90fe96b187)
_dbus_change_to_daemon_user moved into selinux.c for the --with-selinux
(and audit) case because that's where all of the relevant libcap headers
were being used. However in the --disable-selinux case this didn't
compile and wasn't very clean.
If we don't have libaudit, use the legacy direct setgid/setuid bits
we had before in dbus-sysdeps-util-unix.c.
_dbus_change_to_daemon_user moved into selinux.c for the --with-selinux
(and audit) case because that's where all of the relevant libcap headers
were being used. However in the --disable-selinux case this didn't
compile and wasn't very clean.
If we don't have libaudit, use the legacy direct setgid/setuid bits
we had before in dbus-sysdeps-util-unix.c.
We were incorrectly passing NULL for a DBusList when the usage expected
is a pointer to a NULL DBusList pointer. Also during dbus_shutdown
we need to actually close the inotify fd, and remove our watch.
Move the shutdown handler out of bus.c and into inotify where we
can do all of this cleanly.
Substantially based on a patch by Matthias Clasen <mclasen@redhat.com>
kqueue implementation by Joe Marcus Clarke <marcus@freebsd.org>
Previously, when we detected a configuration change (which included
the set of config directories to monitor for changes), we would
simply drop all watches, then readd them.
The problem with this is that it introduced a race condition where
we might not be watching one of the config directories for changes.
Rather than dropping and readding, change the OS-dependent monitoring
API to simply take a new set of directories to monitor. Implicit
in this is that the OS-specific layer needs to keep track of the
previously monitored set.
The reload handling for activation simply dropped all knowledge
of pending activations, which was clearly wrong. Refactor things
so that reload only reloads directories, server address etc.
Based on a patch originally from Matthias Clasen <mclasen@redhat.com>
(Commit message written by Colin Walters <walters@verbum.org>)
A current Fedora goal is to convert projects to libcap-ng which
more easily allows dropping Linux capabilities. For software
which also links to libdbus, it's problematic to link against
libcap as well.
Though really, libdbus should have never linked against libcap
in the first place, which is another thing this patch changes
by moving the libcap-using bits out of dbus/ and into bus/.
https://bugzilla.redhat.com/show_bug.cgi?id=518541
A variety of system components have migrated from legacy init into DBus
service activation. Many of these system components "daemonize", which
involves forking. The DBus activation system treated an exit as an
activation failure, assuming that the child process which grabbed the
DBus name didn't run first.
While we're in here, also differentiate in this code path between the
servicehelper (system) versus direct activation (session) paths. In
the session activation path our error message mentioned a helper
process which was confusing, since none was involved.
Based on a patch and debugging research from Ray Strode <rstrode@redhat.com>
In my informal studies of "normal" sets of match rules, only checking
match rules with the appropriate interface for the message reduces the
number that need to be checked by almost 100x on average (ranging from
halving for messages from the bus daemon, to a >200x reduction in many
cases). This reduces the overhead added to dispatching each message by
having lots of irrelevant match rules.
This is currently not a big deal, but will make more of a difference
once the set of match rules is partitioned by more features than just
the message type.
A variety of system components have migrated from legacy init into DBus
service activation. Many of these system components "daemonize", which
involves forking. The DBus activation system treated an exit as an
activation failure, assuming that the child process which grabbed the
DBus name didn't run first.
While we're in here, also differentiate in this code path between the
servicehelper (system) versus direct activation (session) paths. In
the session activation path our error message mentioned a helper
process which was confusing, since none was involved.
Based on a patch and debugging research from Ray Strode <rstrode@redhat.com>
Replace dbus_daemon_init() by dbus_publish_session_bus_address(),
publishing the full address. Omit username from mutexes (not necessary
as mutex names are local to session). Don't exit if publishing the
address failed (allow multiple session bus instances per
session). Based on 00ee92ae314 by Tor Lillqvist.
Cherry-picked from commit 23945513e9a4da61d286ebfbce3897aa061ddbfe in
the dbus4win repository by tml@iki.fi. Remove claim of that commit not
being merged from README.dbus4win.
On Linux, dbus-daemon and dbus-daemon-launch-helper are treated specially
because they need permission adjustment.
On Windows, all executables are stubs, created by libtool. The real
executables are in .libs. We need to use libtool to install them
properly. So let's make them bin_PROGRAMS on Windows.
(cherry picked from commit 7fb35992d67433ac3ba82e9e2e786e123323456d)
