about using privileged (KAuth) helpers: system dbus daemon on OS X?

Thiago Macieira thiago at kde.org
Mon Sep 19 16:04:05 UTC 2016

On segunda-feira, 19 de setembro de 2016 10:01:01 PDT René J.V. Bertin wrote:
> On Sunday September 18 2016 19:11:56 Thiago Macieira wrote:
> >Applications connect to the bus they were designed to connect to. If they
> >can't, they exit with error.
> >
> >Could not connect to D-Bus server: org.freedesktop.DBus.Error.NotSupported:
> >Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
> OK, then what should a service executable do to connect to the system bus?
> Clearly this is done correctly for Linux and there's no platform-specific
> code in the code (KAuth framework) I'm working on, so we're back in dbus
> land.

Just connect. The system bus is always running on Linux.

> On OS X, the service exec connects to the bus socket pointed to by a single
> env. variable (DBUS_LAUNCHD_SESSION_BUS_SOCKET) that's obtained in a
> dedicated function. I can hijack that variable to point to the system bus
> socket but it would of course be nicer to complete that function with a
> mechanism to check for and read DBUS_LAUNCHD_SYSTEM_BUS_SOCKET.

You get to choose what to do.

The thinking up to here was that there's no reason to run a system bus on 
macOS or on Windows. The system bus exists for system-wide services to offer 
services and for applications to reach those system-wide services.

Those system-wide services don't exist on macOS or Windows. You're not going 
to run BlueZ, Avahi, UPower or UDisks on those systems because they have 
replacements that are native. Arguably, Polkit would make sense to run, but 
only because there is no equivalent on those systems. Still, it wouldn't be 
the normal behaviour expected by the users, so I'd advise against Polkit too.

Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

More information about the dbus mailing list