Havoc, do you have any specific <deny> rule example in mind, that would be evaluated incorrectly by dbus if Joachim's patch is applied?
Additionally, is this actually a problem with dbus itself, or rather issue of default policy in system.conf? Reading the dbus-daemon manpage [1], it contains following:
The [send|receive]_requested_reply attribute works similarly to the
eavesdrop attribute. It controls whether the <deny> or <allow> matches
a reply that is expected (corresponds to a previous method call message).
**This attribute only makes sense for reply messages (errors and method
returns), and is ignored for other message types.**
If I read it correctly, it basically says: if message type is not error or method return, attribute (not the whole rule) is ignored. So according to that sematics definition, for method call message the rule:
<allow send_requested_reply="true"/>
should be identical to:
<allow/>
So the code seems to do exactly what is specified.
Isn't it the default configuration to be blamed for this problem? It says:
<allow send_requested_reply="true"/>
and expects this rule only to be applied to reply messages. This probably needs to be changed to:
Havoc, do you have any specific <deny> rule example in mind, that would be evaluated incorrectly by dbus if Joachim's patch is applied?
Additionally, is this actually a problem with dbus itself, or rather issue of default policy in system.conf? Reading the dbus-daemon manpage [1], it contains following:
[1] http:// dbus.freedeskto p.org/doc/ dbus-daemon. 1.html
The [send|receive] _requested_ reply attribute works similarly to the
eavesdrop attribute. It controls whether the <deny> or <allow> matches
a reply that is expected (corresponds to a previous method call message).
**This attribute only makes sense for reply messages (errors and method
returns), and is ignored for other message types.**
If I read it correctly, it basically says: if message type is not error or method return, attribute (not the whole rule) is ignored. So according to that sematics definition, for method call message the rule:
<allow send_requested_ reply=" true"/>
should be identical to:
<allow/>
So the code seems to do exactly what is specified.
Isn't it the default configuration to be blamed for this problem? It says:
<allow send_requested_ reply=" true"/>
and expects this rule only to be applied to reply messages. This probably needs to be changed to:
<allow send_requested_ reply=" true" send_type= "method_ return" /> reply=" true" send_type="error"/>
<allow send_requested_
I do understand that Joachim's patch changes semantics for non-reply messages from "attribute is ignored" to "whole rule is ignored".
Additionally, your suggestion does not seem to do the right thing either. Consider call message and rule:
<allow send_destinatio n="org. designfu. SampleService" />
If I'm reading the man page correctly, send_requested_ reply=" true" is implied by default. In that case,
if (!requested_reply && rule->allow && rule->d. send.requested_ reply)
should be true, and
if (dbus_message_ get_reply_ serial (message) != 0 && rule->d. send.eavesdrop)
should be false and the rule is skipped.
I'm likely to miss something important, so feel free to correct me in whatever I got wrong. Thanks!