Passing file descriptors over DBUS

[Waldo Bastian]

On Thursday 08 September 2005 12:48, Waldo Bastian wrote:
> On Thursday 08 September 2005 02:03, Havoc Pennington wrote:
> > On Wed, 2005-09-07 at 17:43 +0200, Waldo Bastian wrote:
> > > In order to make the X server more flexible in handling configuration
> > > changes one of the ideas so far is to use DBUS (either via the session
> > > bus, or via a P2P connection) to tell the X server about it's
> > > configuration. For that to work in a secure way, one of the
> > > requirements is to have the ability to pass an open file descriptor
> > > across DBUS. (See man 7 unix, SCM_RIGHTS)
> > >
> > > What are my chances of getting such functionality adopted in DBUS?
> >
> > Here's some past discussion:
> >
> > http://lists.freedesktop.org/archives/dbus/2004-October/001690.html
> > http://lists.freedesktop.org/archives/dbus/2004-October/001691.html
> > http://lists.freedesktop.org/archives/dbus/2004-November/001692.html
>
> Oh, I'm not alone :-) That's encouraging.
>
> > Basic conclusion then seemed to be, we couldn't figure out how to
> > implement it, or at least that it would be a lot of work and raise some
> > complicated issues. But it may be that there are simple solutions given
> > enough thought.
>
> The fact that messages get routed through the daemon make things slightly
> more complicated.
>
> I think it should be possible to have an extension to say at the wire
> level, "this message contains a filedescriptor". Implementation wise you
> would need to tie the file descriptor to DBusMessage, you can essentially
> refcount the file descriptor by dup()-ing it. So once you put the file
> descriptor in the message it will get dup'ed and the caller is free to
> close his own file descriptor. A big question is whether DBUS can close the
> file descriptor directly after sending the message across the socket or
> whether it needs to wait till the other side has actually picked it up. The
> latter case would slightly complicate things.

I looked into this a bit more and it seems that the sending site can close the 
file descriptor directly after it has been send out. The only thing to take 
care of is that the receiving side must listen for the file descriptor at the  
right point in the stream. So if "Message 2" had a file descriptor attached 
the data stream on the wire would like:

<Message 1>
<Message 2>
<File Descriptor>
<Message 3>

After the receiving side has received Message 2, it must read the file 
descriptor with recvmsg() before it can continue reading Message 3.

At the moment the code in dbus-transport-unix.c that reads from the socket, 
just seems to read from the socket as much as it can without being aware of 
message boundaries, that's something that would need some adjustment.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050908/f6b1d2f9/attachment.pgp