moving file descriptor passing into a header
marcus.brinkmann at ruhr-uni-bochum.de
Tue Apr 13 16:19:32 PDT 2010
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.
More information about the dbus