DBus on "other" platforms

René J.V. Bertin rjvbertin at gmail.com
Thu May 12 20:07:10 UTC 2016


On Thursday May 12 2016 18:18:10 Simon McVittie wrote:

> > So we'd be looking at patching GLib and libdbus?
> 
> You'd be looking at making changes to GLib and maybe libdbus that,
> unlike disabling EXTERNAL authentication, are of a quality that can go
> upstream, at which point you no longer need to carry a patch that
> reduces security, and everyone wins.

That's what I meant. Patches aren't necessarily kludges ;)

> 
> It's possible that libdbus already knows how to do credentials-passing
> on OS X. Try running "test/test-dbus-daemon --tap" (to get this
> compiled, you have to build dbus with --enable-modular-tests, which
> requires GLib). If you see something like
> 
>     # ProcessID of this process is 12345
>     # UnixUserID of this process is 678

I'm seeing this:

/creds: Failed to start message bus: Socket name too long

Is that because I already have my session bus running?

> It looks as though this may still be a real issue: poll() on Darwin/OS X
> seems to just be very poorly implemented, unless something has changed
> in the last few years. I'm surprised by this, because surely it works
> fine on the *BSD from which Darwin was forked...

I guess the poll() function invokes some kernel function, and OS X has a very different kernel than what's common on *BSD ...

> In practice D-Bus actually only polls sockets, pipes, inotify
> descriptors (Linux and anything that copied the API, like QNX) and
> kqueue descriptors (FreeBSD and anything that copied that API), so we
> might even be able to get away with using Darwin's broken poll(). 

Because you're not polling devices, right?

> On the
> other hand, the typical symptom of it not working would be a busy-loop,
> which is not what we want.

The broken poll check doesn't busy-loop on /dev/null, if that's any consolation :)
How soon would one hit the busy-loop or other issues? Is there a unittest that does some form of stress-testing of poll() without requiring the running dbus daemon to be built under the assumption poll() works?

R.


More information about the dbus mailing list