Functions like become_monitor() sometimes iterate the main context,
which could leave us with unprocessed messages in f->monitored.
We need to drain that queue of unprocessed messages (setting flags
accordingly, which might meet the loop's exit condition or cause
a break) before we are willing to block in the main context again.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89222
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>
