2003-10-14 Havoc Pennington <hp@redhat.com>

	* bus/bus.c (bus_context_check_security_policy): revamp this to
	work more sanely with new policy-based requested reply setup

	* bus/connection.c (bus_transaction_send_from_driver): set bus
	driver messages as no reply

	* bus/policy.c (bus_client_policy_check_can_receive): handle a
	requested_reply attribute on allow/deny rules

	* bus/system.conf: add <allow requested_reply="true"/>

	* bus/driver.c (bus_driver_handle_message): fix check for replies
	sent to the bus driver, which was backward. How did this ever work
	at all though? I think I'm missing something.

	* dbus/dbus-message.c (decode_header_data): require error and
	method return messages to have a reply serial field to be valid
	(_dbus_message_loader_queue_messages): break up this function;
	validate that reply serial and plain serial are nonzero;
	clean up the OOM/error handling.
	(get_uint_field): don't return -1 from this
	(dbus_message_create_header): fix signed/unsigned bug

	* bus/connection.c (bus_connections_expect_reply): save serial of
	the incoming message, not reply serial

1 files changed, 23 insertions, 2 deletions

diff --git a/bus/dbus-daemon-1.1.in b/bus/dbus-daemon-1.1.in
index 06bbbd13..7e186e51 100644
--- a/bus/dbus-daemon-1.1.in
+++ b/bus/dbus-daemon-1.1.in
@@ -356,7 +356,8 @@ The possible attributes of these elements are:
    receive_sender="service_name" 
    receive_type="method_call" | "method_return" | "signal" | "error"
    receive_path="/path/name"
-   
+
+   requested_reply="true" | "false"
    eavesdrop="true" | "false"
 
    own="servicename"
@@ -377,7 +378,7 @@ Examples:
 .fi
 
 .PP
-The <deny> attributes determine whether the deny "matches" a
+The <deny> element's attributes determine whether the deny "matches" a
 particular action. If it matches, the action is denied (unless later
 rules in the config file allow it).
 
@@ -408,6 +409,26 @@ also, but here it means that the rule applies always, even when
 not eavesdropping. The eavesdrop attribute can only be combined with
 receive rules (with receive_* attributes).
 
+
+.PP
+The 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.
+
+.PP
+For <allow>, requested_reply="true" is the default and indicates that
+only requested replies are allowed by the
+rule. requested_reply="false" means that the rule allows any reply
+even if unexpected.
+
+.PP
+For <deny>, requested_reply="false" is the default but indicates that
+the rule matches only when the reply was not
+requested. requested_reply="true" indicates that the rule applies
+always, regardless of pending reply state.
+
 .PP
 user and group denials mean that the given user or group may 
 not connect to the message bus.