GDBusServer should indicate the authenticated identity of DBUS_COOKIE_SHA1 users
The D-Bus authentication handshake goes like this:
-
Server decides which SASL mechanisms it is prepared to accept
-
Authentication: Client authenticates using a SASL mechanism, a process that normally starts by announcing which authorization identity it wishes to be. The SASL mechanisms supported by practical D-Bus implementation mechanisms are approximately these:
-
EXTERNAL
:- C: I am uid 1000
- S: (looks at socket credentials)
- S: OK, I believe you
-
DBUS_COOKIE_SHA1
:- C: I am uid 1000
- S: (creates a file with a secret "cookie" in uid 1000's
~/.dbus-keyrings
) - S: If you are really uid 1000, you should be able to read
~/.dbus-keyrings/...
and tell me the SHA-1 of a string that includes secret "cookie" number 3 - C: I can! The SHA-1 you asked for is ...
- S: Good enough for me
-
ANONYMOUS
:- C: I'm nobody important
- S: ... I suppose I can't argue with that
-
-
Authorization: Server considers whether the authenticated authorization identity is allowed to connect to this bus or not. If not, it closes the connection.
On Windows it's the same, but Windows doesn't use numeric uids, so instead of claiming to have uid 1000, the client might announce that it has SID S-1-5-18 (which is Windows' internal representation of the LOCAL_SYSTEM
user, in the string form returned by ConvertSidToStringSid()
). The rest of the protocol is identical.
When the client successfully used EXTERNAL
, the authorize-authenticated-peer
signal includes a non-NULL GCredentials
object which the server can use to check who it is authorizing.
However, when the client used either ANONYMOUS
or DBUS_COOKIE_SHA1
, the signal includes a NULL GCredentials
pointer. The server cannot tell whether the client authenticated with ANONYMOUS
, DBUS_COOKIE_SHA1
, or some as-yet-unimplemented SASL mechanism like PLAIN
, KERBEROS_V5
or GSSAPI
.
Servers should have access to the authorization identity when they are making their authorization decision.