hallyn
commented
10 years ago Actually this would be 'client may send SCM_CREDS', not must.
Note the SCM_CREDs are not for authenticating the client, but for translating pids and uids across namspaces in the kernel.
Currently we are sending the dbus_message, then sending the scm_cred, then getting the reply. THe two main downsides to this are that (1) auto-generated client code does not send the scm_creds, and (2) the server ends up waiting (pausing all other requests, I assume) for the SCM_CRED, which actually may not come. It would be nice if dbus could asynchronously wait for the scm_cred for, say 2 seconds, and call our handler with either the credentials or NULL so we know what to do without any delays.
Hi Scott,
We're using NIH for https://github.com/cgmanager/cgmanager. However, we need to use SCM_CRED/SCM_CREDENTIALS which is not supported by dbus on Linux.
We were therefore wondering about the possibility of adding a new D-Bus annotation to nih-dbus-tool say "client must send SCM creds with this method". FWICS, annotations only affect the tools that generate bindings code but are also some sort of loose contract between the D-Bus client and the server.
The D-Bus spec only seems to touch on the precise meaning of annotations very lightly unless I'm missing something. The D-Bus tutorial does cover them in a little more detail, but it seems unreasonable to consider the tutorial part of the official spec to me.
What the spec does refer to is "well-known" annotations which implies that other annotations may be possible? Indeed, I notice that although NIH supports async methods it does so using "com.netsplit.Nih.Method.Async" rather than the semi-well-known "org.freedesktop.DBus.GLib.Async" (semi since it's not in the spec, but is in the tutorial!)
Can you offer any advice or insight into this?
Cheers,
James.