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

[Thiago Macieira]

On segunda-feira, 19 de setembro de 2016 21:51:14 PDT René J.V. Bertin wrote:
> On Monday September 19 2016 09:04:05 Thiago Macieira wrote:
> >Just connect. The system bus is always running on Linux.
> 
> Let me rephrase. How does an application indicate it wants to connect to the
> system bus, and what function(s) is/are called from libdbus to determine
> the socket name? I have looked at the code and understand that the bus
> address isn't looked up from an env. variable.

It calls dbus_bus_get or dbus_bus_get_private with the enum indicating the 
system bus.

Internally, the code has a couple of paths to use to find the address, 
including using an environment variable, but the most common scenario on Linux 
is that it uses the hardcoded internal of /var/run/dbus/system_bus_socket.

> >> 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.
> 
> That doesn't help too much :) My current patch for the dbus helper tool sets
> DBUS_LAUNCHD_SESSION_BUS_SOCKET to the system socket before calling the
> service exec, which works but may have side-effect I haven't foreseen.
> 
> I would like the implementation to be as light and transparent as possible,
> i.e. client code designed to connect to the system bus should do so too on
> OS X. Some clients already do this correctly, like qdbus and qdbusviewer,
> but the services execs I've tried until now fail, apparently because
> libdbus will by default only attempt to connect to a session bus.

Again: the application chooses what to do.

And like I said in the email that you replied to: it doesn't make sense to 
connect to the system bus on macOS and Windows because there are no system 
services to be found there.

> A related question: is there a reason why DBUS_LAUNCHD_SESSION_BUS_SOCKET is
> only queried from launchd and not from the environment?

Probably. But I wouldn't know, I don't know how launchd works.

> >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
> Many don't, but that doesn't mean that there are none that could be used.

That hasn't been the case.

> >to run BlueZ, Avahi, UPower or UDisks on those systems because they have
> >replacements that are native.
> 
> In fact, we do run Avahi, because cross-platform software isn't necessarily
> rewritten to use the native mDNS APIs (Avahi itself may though, on OS X. I
> never checked).

Cross-platform software should be written to use the native system services, 
not rely on a Linux equivalent software to have been ported to the OS in 
question and wrap the native API that the OS already provided.

> There may also be cross-platform (read: Qt/KF5) software for controlling
> specific hardware that needs to be able to perform certain operations with
> elevated privileges. Or a future version of the VirtualBox GUI (written in
> Qt) might remove the need for the user of VMs using direct-access virtual
> disks to adjust the permissions of the disk device (and there's no native
> interface for that other than sudo and chown/chmod :)).

Elevating privileges is a native OS operation because, by definition, you're 
doing some kind of system administration. I don't think there should be a 
cross-platform solution for this. If you're going to do system administration, 
write platform-specific code.

> >the normal behaviour expected by the users, so I'd advise against Polkit
> >too.
> Careful with that on the DBus ML, there are already enough people who advise
> against DBus on OS X or MS Windows too ;)

D-Bus on macOS and on Windows for the session bus is fine. It's just yet-
another-IPC for applications to exchange data through. It may not be the 
fastest solution (I remember QNX benchmarking it and finding their native 
implementation was better), but it's a reasonable solution.

System bus, however, hasn't made sense on those OSes. That's why there is no 
way to autolaunch them on Mac and Windows. If you want to change that, be our 
guest. You know more about macOS than the rest of the D-Bus community, so 
we'll follow your lead.

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