From 3251264ac483680b4a5fe808729f7e3b34f41fd4 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Tue, 14 Oct 2003 22:16:03 +0000 Subject: 2003-10-14 Havoc Pennington * 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 * 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 --- doc/dbus-specification.xml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/dbus-specification.xml') diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 698e35a2..807769b7 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -644,6 +644,11 @@ reply is expected, so the caller will know the method was successfully processed. + + The METHOD_RETURN or ERROR reply message MUST have the REPLY_SERIAL + header field. If this field is missing, it should be treated as + a corrupt message. + If a METHOD_CALL message has the flag NO_REPLY_EXPECTED, then as an optimization the application receiving the method -- cgit