Attachment 136117 Details for Bug 104224 – [9/9] spec: Describe the EXTERNAL and ANONYMOUS auth mechanisms

[patch] [9/9] spec: Describe the EXTERNAL and ANONYMOUS auth mechanisms

0009-spec-Describe-the-EXTERNAL-and-ANONYMOUS-auth-mechan.patch (text/plain), 4.78 KB, created by Simon McVittie on 2017-12-12 16:01:43 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Simon McVittie

Created: 2017-12-12 16:01:43 UTC

Size: 4.78 KB

patch

obsolete

>From a51b57df7a3771b7ff783efad6f56f50af20263c Mon Sep 17 00:00:00 2001
>From: Simon McVittie <smcv@collabora.com>
>Date: Tue, 12 Dec 2017 13:36:24 +0000
>Subject: [PATCH 9/9] spec: Describe the EXTERNAL and ANONYMOUS auth mechanisms
>
>These are defined by standard RFCs rather than by D-Bus. What
>separates them from other standard mechanisms like	PLAIN (RFC 4616)
>is that in practice, D-Bus implementations support EXTERNAL,
>DBUS_COOKIE_SHA1 and sometimes ANONYMOUS, but not PLAIN.
>
>Signed-off-by: Simon McVittie <smcv@collabora.com>
>---
> doc/dbus-specification.xml | 63 ++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 58 insertions(+), 5 deletions(-)
>
>diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml
>index 90b24db2..1ec07a59 100644
>--- a/doc/dbus-specification.xml
>+++ b/doc/dbus-specification.xml
>@@ -3065,18 +3065,59 @@
>     <sect2 id="auth-mechanisms">
>       <title>Authentication mechanisms</title>
>       <para>
>-        This section describes some new authentication mechanisms.
>-        D-Bus also allows any standard SASL mechanism of course.
>-      </para>
>+        This section describes some authentication mechanisms that are
>+        often supported by practical D-Bus implementations. The D-Bus
>+        protocol also allows any other standard SASL mechanism, although
>+        implementations of D-Bus often do not.
>+      </para>
>+      <sect3 id="auth-mechanisms-external">
>+        <title>EXTERNAL</title>
>+        <para>
>+          The EXTERNAL mechanism is defined in <ulink
>+            url="https://tools.ietf.org/html/rfc4422#appendix-A">RFC 4422
>+            "Simple Authentication and Security Layer (SASL)", appendix A
>+            "The SASL EXTERNAL Mechanism"</ulink>. This is the recommended
>+          authentication mechanism on platforms where credentials can be
>+          transferred out-of-band, in particular Unix platforms that can
>+          perform credentials-passing over the
>+          <link linkend="transports-unix-domain-sockets-addresses"
>+            >unix: transport</link>.
>+        </para>
>+        <para>
>+          On Unix platforms, interoperable clients should prefer to send
>+          the ASCII decimal string form of the integer Unix user ID as
>+          the authorization identity, for example 1000. When encoded in
>+          hex by the authentication protocol, this will typically result
>+          in a line like <literal>AUTH EXTERNAL 31303030</literal> followed
>+          by \r\n.
>+        </para>
>+        <para>
>+          On Windows platforms, clients that use the EXTERNAL mechanism
>+          should use the Windows security identifier in its string form
>+          as the authorization identity, for example
>+          <literal>S-1-5-21-3623811015-3361044348-30300820-1013</literal> for
>+          a domain or local computer user or <literal>S-1-5-18</literal> for
>+          the LOCAL_SYSTEM user. When encoded in hex by the authentication
>+          protocol, this will typically result in a line like
>+          <literal>AUTH EXTERNAL 532d312d352d3138</literal> followed by
>+          \r\n.
>+        </para>
>+      </sect3>
>       <sect3 id="auth-mechanisms-sha">
>         <title>DBUS_COOKIE_SHA1</title>
>         <para>
>-          The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client
>+          DBUS_COOKIE_SHA1 is a D-Bus-specific SASL mechanism. Its
>+          reference implementation is part of the reference implementation
>+          of D-Bus.
>+        </para>
>+        <para>
>+          This mechanism is designed to establish that a client
>           has the ability to read a private file owned by the user being
>           authenticated. If the client can prove that it has access to a secret
>           cookie stored in this file, then the client is authenticated.
>           Thus the security of DBUS_COOKIE_SHA1 depends on a secure home
>-          directory.
>+          directory. This is the recommended authentication mechanism
>+          for platforms and configurations where EXTERNAL cannot be used.
>         </para>
>         <para>
>           Throughout this description, "hex encoding" must output the digits
>@@ -3212,6 +3253,18 @@
>           because servers are required to save the file atomically.
>         </para>
>       </sect3>
>+      <sect3 id="auth-mechanisms-anonymous">
>+        <title>ANONYMOUS</title>
>+        <para>
>+          The ANONYMOUS mechanism is defined in <ulink
>+            url="https://tools.ietf.org/html/rfc4505">RFC 4505 "Anonymous
>+            Simple Authentication and Security Layer (SASL)
>+            Mechanism"</ulink>.
>+          It does not perform any authentication at all, and should not
>+          be accepted by message buses. However, it might sometimes be
>+          useful for non-message-bus uses of D-Bus.
>+        </para>
>+      </sect3>
>     </sect2>
>   </sect1>
>   <sect1 id="addresses">
>-- 
>2.15.1
>

Actions: View | Splinter Review

Attachments on bug 104224: 136109 | 136110 | 136111 | 136112 | 136113 | 136114 | 136115 | 136116 | 136117 | 136277 | 136278 | 136279 | 136280 | 136281 | 136282

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.