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

[René J.V. Bertin]

On Friday September 23 2016 14:38:01 Simon McVittie wrote:

>I have no idea why the launchd support works like this.

Launchd support does seem to be rather minimal. It is also implemented in such a way that other code paths are deactivated, i.e. as an alternative code path selected at build time.

>I would expect that it should work more like autolaunch:, with the
>default DBUS_SESSION_BUS_CONNECT_ADDRESS perhaps being
>"launchd:,autolaunch:" when compiled with launchd support, and

I have seen references to a different syntax, "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET". I don't fully understand the exact intentions of that syntax. If I understand correctly it is suggested that this should allow autolaunching but I see nothing in the code that would do that.
*Maybe* one should understand this as "if launchd has loaded the dbus-session plist once and that contains a socket name DBUS_LAUNCHD_SESSION_BUS_SOCKET, then any attempt to read the value of that variable through launchd will lead to the sessiondbus being started".

If that is indeed the case, then a similar mechanism could be designed for DBUS_LAUNCHD_SYSTEM_BUS_SOCKET, knowing that in that case the system socket will always be at a different address. That's going to make it difficult to read the variable for all processes that don't run as the dbus user (messagebus), at least if we want to be able to do it via `launchtl getenv` instead of via a regular getenv().

>See also <https://bugs.freedesktop.org/show_bug.cgi?id=74029>, which as
>far as I can see would be solved if launchd support behaved like a
>normal transport.

That situation seems to be calling for a system bus. Should that one really be launcheable by the first client that wants to connect to it? How would we resolve the issue that it must run as a specific user, typically not the UID of the client?
The ticket isn't very clear despite its exhaustiveness. Does the reported issue arise for users who've done the reglementary `launchd load -w org.freedesktop.dbus-session.plist`, for instance?

>See also <https://bugs.freedesktop.org/show_bug.cgi?id=58601>, which
>asks for a specification for this transport.

Hmm, who designed and committed launchd support?

The way I understand it, clients do not need "to get the address" at least not to connect to the session bus.
Maybe the function exists already but if not, couldn't libdbus provide a library function that returns the address of the requested bus type, as a string? On OS X that would return `launchctl getenv DBUS_LAUNCHD_SESSION_BUS_SOCKET` for the session bus and the usual values for the other bus types, possibly NULL for any bus that isn't running.

R.