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>
Packagers should only enable this flag if they have confirmed that it
actually works on their toolchain (it's the sort of rarely used feature
that frequently regresses on obscure architectures/OSs without anyone
noticing), and also confirmed that it is actually a significant size win
for their configuration.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33466
Reviewed-by: Colin Walters <walters@verbum.org>
On Linux, we previously called openlog() (with different options!) while
initializing SELinux; leave SELinux messages as LOG_USER|LOG_INFO in case
anyone was relying on that, but let the rest of our log messages come
out as LOG_DAEMON.
Also enable LOG_PERROR (copy syslog messages to stderr) unconditionally;
we can make this an autoconf check if anyone's pet Unix doesn't have
LOG_PERROR.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35358
Reviewed-by: Colin Walters <walters@verbum.org>
In practice, nothing copes with missing broadcast signals, so the least
we can do is make the failure mode visible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35358
Reviewed-by: Colin Walters <walters@verbum.org>
This is necessary to run the regression tests under valgrind (if
telling it to output to a dedicated fd), gdb, fakeroot etc.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35173
Reviewed-by: Colin Walters <walters@verbum.org>
It's a minor security benefit, but not automatically beneficial (it
enables ASLR, but breaks prelinking, some buggy toolchains, and some gdb
versions). Distributions who know their infrastructure works well can
enable it just as easily via
./configure CFLAGS="-fPIE" LDFLAGS="-pie"
without extra support from us, and that's a generic solution applicable to
many packages.
Similarly, don't force libdbus and libdbus-internal to be PIC: libtool
knows better than we do whether that's necessary/beneficial on a
particular platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=16621
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27215
Bug-NB: NB#171940
Reviewed-by: Colin Walters <walters@verbum.org>
Also remove some pointless indirection (extra_tests etc.), don't install
the unused directory $(libexecdir)/dbus-1 (we actually install the
launch helper directly into $(libexecdir)), and allow dbus_daemondir to be
set on Windows rather than forcing dbus-daemon to be installed to
$(bindir) there.
dbus_daemon_execdir has to contain "exec" so that the dbus-daemon will be
installed by "make install-exec" and not "make install-data".
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=14512
Reviewed-by: Colin Walters <walters@verbum.org>
In commit:
075945f6 (John (J5) Palmieri 2005-07-14 20:44:15 +0000
some code was added to compare services by Exec key. The changelog is
not pariticularly informative as to why this was added. But while
debugging other code, we noticed this.
Comparing by Exec key is not in the specification, and triggered a
problem where while converting services to use systemd for activation,
a change was made to use Exec=/bin/false and simply rely on systemd
to activate.
While I think it was broken for the service files to be changed
to Exec=/bin/false, we shouldn't be doing something here that's
not in the spec either.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35750
Also disallow having both path and path_namespace in the same match rule
(it wouldn't make sense, path is more specific than path_namespace).
As per IRC discussion with davidz and wjt.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34870
Add a new path_prefix match rule that can be used for efficient
implementations of the org.freedesktop.DBus.ObjectManager interface
(see bug 34869).
https://bugs.freedesktop.org/show_bug.cgi?id=34870
Signed-off-by: David Zeuthen <davidz@redhat.com>
This makes use of UnknownInterface and UnknownObject where appropriate
in the D-Bus core.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34527
Reviewed-By: Simon McVittie <simon.mcvittie@collabora.co.uk>