From 839f0c248496b16412b508a7d74d31faf93afba7 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 3 Sep 2014 20:19:36 +0200 Subject: [PATCH] dbus-spec: introduce new PERMIT_INTERACTIVE_AUTHENTICATION As discussed earlier on the dbus mailing list, let's add a new flag to the message header, that allows clients to indicate whether they are OK with possiably time-intensive interactive authentication. This is useful for authentication frameworks such as polkit, but this flag is supposed to be generic, and not be bound to any implementation of such a framework. The dbus specification already clarifies that unknown flags must be ignored, the reference implementation and the other implementations i checked indeed ignore any new flags, hence we should be fine with compatibility here. THis patch simply updates the spec, it does not add new APIs for this to the reference implementation. --- doc/dbus-specification.xml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 1b740fe..3fdc9bb 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1351,6 +1351,30 @@ for the destination name in response to this message. + + PERMIT_INTERACTIVE_AUTHENTICATION + 0x4 + This is a hint that may be set on a method call + message that informs the receiving side that the + caller is OK if possibly time-intensive interactive + user authentication may take place before the method + call will complete. A client may set this flag if it + is prepared to wait for a longer time before the + method call returns, and if its UI may be interrupted + by interactively querying the user for passwords or + confirmation. This flag is only useful when + unprivileged code calls a more priviliged method call, + and an authentication framework is deployed that + allows possibly interactive authentication. If no such + framework is deployed it has no effect. This flag + should not be set by default by client + implementations. If it is set the caller also should + set a suitably long timeout on the method call to make + sure the user interaction may complete. This flag is + only valid for method call messages, and shall be + ignored otherwise. + + -- 1.9.3