[patch] gobject sender and pid

[Robert McQueen]

David Zeuthen wrote:
> So how exactly do I do this? The Telepathy sources leads me to using
> something called gengobject.py but it seems this is not part of D-BUS
> and I couldn't find it anywhere though my Google skillz may be weak this
> time of year. Oh, well, so, lazy as I am, I simply tried adding an
> annotation

Our gengobject.py crack can be found in telepathy-python/tools. It's
just to generate stub GObjects given some D-Bus introspection XML. It's
very handy because besides saving the GObject boilerplate, it generates
you the method signatures that dbus-binding-tool expects. Although, Ross
did mention he was thinking of making d-b-t to put those signatures into
the glue .h file, thereby giving you warnings if you implement the wrong
thing. Anyway, putting in the async annocation is the key.

>     <method name="InitiatePrivilegeGrant">
>       <annotation name="org.freedesktop.DBus.GLib.Async" value=""/>
>       <arg name="user"            type="s" direction="in"/>
>       <arg name="privilege"       type="s" direction="in"/>
>       <arg name="resource"        type="s" direction="in"/>
>       <arg name="session_objpath" type="o" direction="out"/>
>     </method>
> 
> but still no dice with dbus-binding-tool. 

Hmm, how no dice? It wouldn't appear to function any differently until
runtime - that annotation should be all you need, then in your method
signature, don't put any out arguments, and instead of a GError, the
last argument is a DBusGMethodInvocation instead.

> Sure, my patch was experimental but it should really be possible to get
> the sender for sync calls too. To write a secure system bus service, you
> really need to know who the caller is.

Does it really matter that much? I don't see any sensible way to attach
a context with things like the sender and path to a synchronous call
without turning it into something which isn't just a straight C method
call. If you do want to involve yourself in the bus more closely and get
an object representing the context of the call, this is what exactly
what the async annotation does - I don't regard it as an abuse.

> Thanks,
> David

Regards,
Rob