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

[René J.V. Bertin]

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.
>> 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.

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

>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.

>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).

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 :)).

>Arguably, Polkit would make sense to run, but 
>only because there is no equivalent on those systems. Still, it wouldn't be 

There is on OS X: the Security Framework and the Service Management framework. The KAuth KF5 framework is already based on Security.framework for obtaining authorisation, instead of using Polkit or PolicyKit.

>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 ;)

Evidently you're not going to be using this kind of framework when the goal is to write applications that are as native as possible, and that solve cross-platform problems by providing their own dedicated backends. That's not the context from which I'm asking my questions. I may consider writing a native alternative to the DBus "helper" backend for KAuth, but if I ever do that it'll be after getting the current code to work so I have a reference implementation to compare against (and one that will show whether the effort is justified).

R.