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.
> >
> >$ DBUS_SESSION_BUS_ADDRESS= DISPLAY= qdbus
> >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