DBus on "other" platforms

Simon McVittie simon.mcvittie at collabora.co.uk
Thu May 12 13:10:49 UTC 2016

On 12/05/16 12:20, René J.V. Bertin wrote:
> On Thursday May 12 2016 12:37:49 Ralf Habacker wrote:
>>> https://trac.macports.org/browser/trunk/dports/devel/dbus/files
>> https://trac.macports.org/browser/trunk/dports/devel/dbus/files/patch-bus-system.conf.in.diff
>> -> This patch is obsolate
> Good to know - even with the DBus version currently in MacPorts?

If MacPorts' dbus integration wants to run dbus-daemon without a pid
file, they can use --nopidfile (available since 1.6.0, which is no
longer security-supported so I hope they aren't running that or anything

Whether to use a pid file, and if so what its name is, should never have
been a configuration file option, because whether a pid file is needed
is a fact about the way the dbus-daemon is launched (init script,
systemd, Upstart, launchd, whatever) - it should have been a
command-line option. However, now that it exists as a config file option
that is relied on by init scripts, we can't remove it; the best we can
do is to provide command-line options that override it.

>> https://trac.macports.org/browser/trunk/dports/devel/dbus/files/patch-configure.diff
> It's just not clear to me what it's supposed to change w.r.t. the
>  default build. Based on the trac ticket
> (https://trac.macports.org/ticket/47741#comment:12) mentioned in the
> comment in the Portfile, it seems the patch disables EXTERNAL
> authentication on OS X

It looks to me as though this is a workaround for GLib's implementation
of D-Bus (GDBus) not knowing how to carry out secure AF_UNIX
credentials-passing (EXTERNAL authentication) on OS X in a way that
would interoperate with libdbus.

On Windows with TCP, DBUS_COOKIE_SHA1 is the least bad thing we can do,
but on Unix with AF_UNIX, it should not be used if there is something
better; and EXTERNAL is better.

If OS X can do credentials-passing across AF_UNIX sockets, then the
correct long-term solution is to get that implemented compatibly in
libdbus and GDBus, and then MacPorts can stop patching libdbus to be
less secure. Unfortunately, credentials-passing is very OS-specific, so
for each OS that will use it, someone needs to implement and test it.

According to the research that I did last time I looked into this, OS X
has at least getpeereid(), so it should be possible to support it in
g_socket_get_credentials(). Since it has FreeBSD ancestry (I think?) it
might well also be able to support G_CREDENTIALS_TYPE_FREEBSD_CMSGCRED
(search GLib source code for __FreeBSD__, it might just be a matter of
adding __darwin__ or something to the __FreeBSD__ #ifdefs). However,
again, this needs to be driven by someone who runs Darwin/OS X, or it
won't happen.

> but it also sets broken_poll to yes (when cross_compiling), for some reason.

I think I've run across this before: if I remember correctly, MacPorts
splits up patches by the file they affect, not the logical change they
make. If true, that's an unfortunate design decision.

Setting that variable makes libdbus ignore the platform's poll()
implementation, and emulate it inefficiently using select() instead.
Does Darwin/OS X in fact have a broken poll() implementation, or is this
a workaround for something?

Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

More information about the dbus mailing list