moving file descriptor passing into a header

[Marcus Brinkmann]

On 04/14/2010 12:36 AM, Lennart Poettering wrote:
> Especially given that that to my knowledge D-Bus on Windows is mostly still a
> pipe dream, if I understand correctly.

Before I go into some detail, please understand that I am not involved in DBus 
design and in fact am only partially familiar with the DBus specification and 
feature set.  The information below is given generally and not intended as an 
argument for or against any of the discussed features here.

Actually DBus on Windows is used in production in the KDE port to Windows, for 
example in the Gpg4Win package that contains the Kleopatra certificate 
manager, and Kontact-for-Windows.  The current port only supports the session 
bus, not the system bus, but this is only because currently nobody requires a 
Windows system bus.

In addition to that, we ported DBus to Windows CE (Windows Mobile 6.5) and 
will use it in production later this year.

In your other mail you wrote:

> This is about passing any kind of fds (files, sockets of all kinds,
> device handles, fs fifosq, socketpair(), pipe(), inotify(), epoll() --
> whatever kind of fd your OS supports) . And yes, this is not portable
> beyond Unix. That's why the type is called DBUS_TYPE_UNIX_FD, not
> DBUS_TYPE_FILE or so.

As far as compatibility is concerned, many systems provide such a mechanism 
for their type of canonical descriptor (or handle), in some way or another, 
although implementation details differ.  I am not sure if all Unix systems 
provide it, though, and implementation across Unix varied considerably 
(although it may have converged by now, or it's just that there are less 
relevant Unix target platforms today).

The underlying principle is certainly an important part of any 
capability-based communication facility, however, in my understanding, the 
dbus design does not aim for that title, so I am not sure the analogy applies 
well here.  There is an important difference between capability systems and 
Unix fds on the one hand and DBus on the other hand: In the former, 
descriptors passed through descriptors are still subject to the same policies 
and access rules as the descriptors they are passed through, ie they belong to 
the same class of objects.  Unix FDs passed through a DBus connection however 
are not subject to DBus policies and controls.  This may complicate reasoning 
about the implications of allowing such desciptor passing (I am not familiar 
with the design enough to say if this is a valid concern or not).

> Or read it this way: if you are afraid that you might not be able to
> demarshall a unix fd on a win32 machine, then fear no longer: nobody
> would want to send you wan on windows in the first place, since he in
> the first place couldn't posess one either that could have any meaning
> to you!

This has little to do with windows vs unix though: A unix fd on one system can 
also not be passed to another unix system, as there is no network transparency 
at the unix kernel level for this feature.  There are systems that provide 
this functionality (distributed capability systems) but they are ver

By the way: Windows can pass HANDLEs (the underlying descriptor object) from 
one process to another just fine, although again the details of the mechanism 
are somewhat different.  As an example for a system which does not provide 
this facility: Windows CE is a very restricted platform and fails to implement 
inter-process HANDLE passing.

Thanks,
Marcus