Since 1.4.4 (commit 75cfd97f) this function always returned FALSE. As far
as I can see this was actually harmless, because both of its callers
ignore any error that is not NoMemory (and treat it the same as success).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
If we're going to return FALSE for this (which has apparently always
been the case), then we should set an error properly.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39230
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
In commit ab7b3f9, Ralf notes that handle_reload_watch() is (in principle)
cross-platform. However, there's no way to trigger it on Windows, because
nothing ever writes to the pipe. Make the entire pipe-to-self trick
Unix-specific instead.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40002
This patch ensures the daemon process doesn't inherit any supplemental
groups for the root user from an administrator login via an init
script.
This is only an issue for pre-systemd systems.
https://bugzilla.redhat.com/show_bug.cgi?id=726953
On OSs with abstract sockets, this is close enough. On OSs without
abstract sockets, this results in failing to clean up Unix sockets
in /tmp if someone has sent us thousands of SIGHUP signals since we
last entered the main loop - I think that's acceptable.
The reload pipe should never get closed, but if it is for some reason,
we want a SIGTERM after that to cause an exit too.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38656
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Signals are POSIX but not ISO C, so guard it with DBUS_UNIX.
dbus-sysdeps-util-win doesn't actually implement _dbus_set_signal_handler
anyway, so not compiling this code on non-Unix seems more honest.
Backported to dbus-1.4, originally part of commit c7ef3ead55.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33336
Reviewed-by: Thiago Macieira <thiago@kde.org>
This patch ensures the daemon process doesn't inherit any supplemental
groups for the root user from an administrator login via an init
script.
This is only an issue for pre-systemd systems.
https://bugzilla.redhat.com/show_bug.cgi?id=726953
Everything in this directory is statically linked to libdbus-internal,
so we can make -DDBUS_STATIC_BUILD global. Also, merge INCLUDES into
AM_CPPFLAGS (it's an older name for the same functionality).
In order to allow D-Bus usage during early boot (where /usr is not
accessible) also search for bus activation files in
/lib/dbus-1/system-services/. This is only a first step in the right
direction, before we really can boot without /usr we'd need to move all
current activation files (or possibly replace
/usr/dbus-1/system-services to a symlink to
/lib/dbus-1/system-services).
Adds "eavesdrop=true" as a match rule, meaning that the owner
intend to eavedrop.
Otherwise the owner will receive only broadcasted messages and the ones
meant to be delivered to it.
[plus a typo fix in an error message -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37890
Bug-NB: NB#269748
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are no actual statistics yet, just a count of how many times the
method has been called, and (for the per-connection stats) the unique name.
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34040
We don't allow match rules with unknown message types, so losing the
"type='%d'" case isn't a great loss.
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34040
Similar to the previous commit, almost every use of DBusWatch can just
have the main loop call dbus_watch_handle.
The one exception is the bus activation code; it's had a comment
explaining why it's wrong since 2003. We should fix that one day, but for
now, just migrate it to a new _dbus_loop_add_watch_full which preserves
the second-layer callback.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33342
Reviewed-by: Thiago Macieira <thiago@kde.org>
Instead of supplying 8 tiny wrapper functions around dbus_timeout_handle,
each with a user_data parameter that's a potentially unsafe borrowed
pointer but isn't actually used, we can call dbus_timeout_handle directly
and save a lot of trouble.
One of the wrappers previously called dbus_timeout_handle repeatedly
if it returned FALSE to indicate OOM, but that timeout's handler never
actually returned FALSE, so there was no practical effect. The rest just
ignore the return, which is documented as OK to do.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33342
Reviewed-by: Thiago Macieira <thiago@kde.org>
client_timeout_callback in bus/test.c refs the connection across the
timeout invocation, which looks suspiciously like a workaround. If we
make the timeout handler itself ref the connection, we won't need that,
and can simplify timeout handling drastically.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33342
Reviewed-by: Thiago Macieira <thiago@kde.org>
_dbus_warn isn't async-signal-safe, so that's out. We can use write()
instead; it's POSIX but not ISO C, but then again, so are signals.
Accordingly, guard it with DBUS_UNIX.
dbus-sysdeps-util-win doesn't actually implement _dbus_set_signal_handler
anyway, so not compiling this code on non-Unix seems more honest.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33336
Reviewed-by: Thiago Macieira <thiago@kde.org>
This should mean we don't get invalid fds in the main loop.
The BSD (kqueue) and Windows code paths are untested, but follow the same
patterns as the tested Linux/generic Unix versions.
DBusTransportSocket was already OK (it called free_watches() before
_dbus_close_socket, and that did the remove, invalidate, unref dance).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33336
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Using $(LN_S) is inappropriate because it could in theory mean either
ln -s, ln or cp -p depending on autoconf checks.
Not using -f breaks reinstallation directly from source (DESTDIR unset),
because the symlinks will already exist.
Because systemd isn't currently portable to non-Linux, let alone
non-SUS-compliant systems, it seems safe to assume that ln -fs behaves
as specified by SUS if systemd was found.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37870
Reviewed-by: Colin Walters <walters@verbum.org>
