Bug 46787: add a way to eavesdrop on the system bus without undesired side-effects - Simon McVittie <smcv@collabora.com> - 2/29/2012 Back to Bug | Your Reviews | Help
Attachment 112858: [PATCH 3/6] Add a regression test for becoming a monitor - Simon McVittie <smcv@collabora.com> - 1/26/2015 (View )

Show Quick Help

From: Simon McVittie <simon.mcvittie@collabora.co.uk>
Date: Fri, 23 Jan 2015 19:21:06 +0000
Subject: [PATCH 3/6] Add a regression test for becoming a monitor
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
Because some of the code here is systemd-specific, I wrote a test-case
for systemd activation, which mostly addresses #57952 as a bonus.
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.
<Overall Comment>
Previous Reviews
Philip Withnall <bugzilla@tecnocode.co.uk>
2/2/2015
-----------------------------------------------------------------
test/monitor.c
1/* Integration tests for monitor-mode D-Bus connections
2 *
3 * Copyright © 2010-2011 Nokia Corporation
The © symbol is corrupted for me, but this could be a Bugzilla/Splinter problem.
450 DBusMessage **message_p = data;
451 
452 *message_p = dbus_pending_call_steal_reply (pc);
453 g_assert (*message_p != NULL);
454}
You have previously factored this out as test_pending_call_store_reply() in bug #88810.
550 g_assert_cmpint (ret, ==, DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER);
551 
552 while (!got_unique || !got_a || !got_b || !got_c)
553 {
554 test_main_context_iterate (f->ctx, TRUE);
It might make sense to add a timeout to this loop so the test can’t continue forever if there’s a bug.
605 become_monitor (f);
606 
607 while (!lost_unique || !lost_a || !lost_b || !lost_c)
608 {
609 test_main_context_iterate (f->ctx, TRUE);
Same here: timeout?
660 g_assert (!dbus_connection_get_is_connected (f->monitor));
661 
662 while (TRUE)
663 {
664 test_main_context_iterate (f->ctx, TRUE);
And here, throughout the rest of the file, etc.
769 "BroadcastSignal1", "", NULL);
770 dbus_message_unref (m);
771 
772 /* FIXME: dbus-daemon does not fake a denial message for the monitor's
773 * benefit; should it? */
Not sure this is addressed in a later patch. Should it be?
I can imagine the monitor being used to diagnose exactly these kinds of denial issues, so I guess a message should be faked.
Powered by Splinter

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.