Possibility of adding a new D-Bus annotation to nih-dbus-tool.

[jamesodhunt]

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.

[hallyn]

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.