This guide gives some pointers on how to write D-Bus APIs which are nice
to use.
It adds an optional dependency on Ducktype and yelp-build from
yelp-tools. These are used when available, but are not required unless
--enable-ducktype-docs is passed to configure. They are required for
uploading the docs, however.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88994
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
- change "ref serial" to "in_reply_to" (avoiding whitespace for easy
visual parsing)
- prefix with # to clarify that these are not part of the data
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89165
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
dbus-send could already pretty-print bytestrings that do not have
\0 termination, but those are awkward to work with (they need copying),
so they are now discouraged. Teach it to print bytestrings that
do have \0 termination as well.
In the process, rewrite this part of the message parser
to use dbus_message_iter_get_fixed_array(), which is the Right way
to get arrays of numbers out of a message.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89109
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This interface contains methods 'EnableVerbose' and 'DisableVerbose'
to control verbose mode on daemon runtime.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88896
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
dbus_connection_get_windows_user is documented to return TRUE but
put NULL in its argument if OOM is reached.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89041
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It was relying on a higher-than-default fd limit; cut it down to
more than 256 but rather less than 1024, since the default Linux
limit is 1024 fds per user.
Also automatically skip this test if our rlimit is too small.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88998
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Without this code change, non-systemd processes can make dbus-daemon
think systemd failed to activate a system service, resulting in an
error reply back to the requester. In practice we can address this in
system.conf by only allowing root to forge these messages, but this
check is the real solution, particularly on systems where root is
not all-powerful.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
We need this, or something equivalent, to address CVE-2015-0245 via
code changes.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
test-marshal and test-syntax need the
$(testutils_shared_if_possible_cppflags), so that they will get the
$(static_cflags) when we are not linking to dbus-glib.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88980
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Move the dbus_connection_add_filter() call further up as a precaution,
because it isn't safe for a monitor to not have a filter that
swallows all messages.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This includes most of the situations I could think of:
* method call on dbus-daemon and response
* NameOwnerChanged
* NameAcquired, NameLost (although I'm not 100% sure these should
get captured, since they're redundant with NameOwnerChanged)
* unicast message is allowed through
* unicast message is rejected by no-sending or no-receiving policy
* broadcast is allowed through
* broadcast is rejected by no-sending policy (the error reply
is also captured)
* broadcast is rejected by no-receiving policy (there is no error
reply)
* message causing service activation, and the message telling systemd
to do the actual activation
* systemd reporting that activation failed
It does not cover:
* sending a message to dbus-daemon, then provoking a reply, then
dbus-daemon does not allow itself to send the reply due to its
own security policy
This is such an obscure corner case that I'm not even convinced it's
testable without dropping down into lower-level socket manipulation:
dbus-daemon's replies are always assumed to be requested replies,
and replies contain so little other metadata that I think we can
only forbid them by forbidding all method replies. If we do that,
the reply to Hello() won't arrive and the client-side connection will
not become active.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Unlike eavesdropping, the point of capture is when the message is
received, except for messages originating inside the dbus-daemon.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This is a special connection that is not allowed to send anything,
and loses all its well-known names.
In future commits, it will get a new set of match rules and the
ability to eavesdrop on messages before the rest of the bus daemon
has had a chance to process them.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Without either this rule or better checking in dbus-daemon, non-systemd
processes can make dbus-daemon think systemd failed to activate a system
service, resulting in an error reply back to the requester.
This is redundant with the fix in the C code (which I consider to be
the real solution), but is likely to be easier to backport.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
