Comment 4 for bug 306362

Revision history for this message
In , Thoger-redhat (thoger-redhat) wrote :

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.freedesktop.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"/>
  <allow send_requested_reply="true" send_type="error"/>

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_destination="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!