From: Lars Uebernickel <lars@uebernic.de>
Date: Mon, 2 Nov 2015 14:47:39 +0000 (+0100)
Subject: Disallow unexpected replies
X-Git-Tag: dbus-1.12.0~546
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=fc255f66f164caa5cd6dc9ea65fcf27a775f528f;p=platform%2Fupstream%2Fdbus.git

Disallow unexpected replies

Allowing to send replies when NO_REPLY_EXPECTED is set is useless in
practice: Clients need to be careful not to send these replies, because
bus policy could deny these messages. The spec even mentions that this
issue exists.

To make this more clear and misbehaving clients less likely, disallow
sending unexpected replies entirely.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75749
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
---

diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml
index 1e0fe20..de152f3 100644
--- a/doc/dbus-specification.xml
+++ b/doc/dbus-specification.xml
@@ -1383,12 +1383,7 @@
                   <para>
                     This message does not expect method return replies or
                     error replies, even if it is of a type that can
-                    have a reply; the reply can be omitted as an
-                    optimization. It is compliant with this specification
-                    to return the reply despite this flag, although doing
-                    so on a bus with a non-trivial security policy
-                    (such as the well-known system bus) may result in
-                    access denial messages being logged for the reply.
+                    have a reply; the reply should be omitted.
                   </para>
                   <para>
                     Note that METHOD_CALL is the only message type currently
@@ -1864,12 +1859,9 @@
           header field.
         </para>
         <para>
-          If a <literal>METHOD_CALL</literal> message has the flag <literal>NO_REPLY_EXPECTED</literal>, 
-          then as an optimization the application receiving the method 
-          call may choose to omit the reply message (regardless of 
-          whether the reply would have been <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>). 
-          However, it is also acceptable to ignore the <literal>NO_REPLY_EXPECTED</literal>
-          flag and reply anyway.
+          If a <literal>METHOD_CALL</literal> message has the flag <literal>NO_REPLY_EXPECTED</literal>,
+          then the application receiving the method should not send the reply message (regardless of
+          whether the reply would have been <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>).
         </para>
         <para>
           Unless a message has the flag <literal>NO_AUTO_START</literal>, if the