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

René J.V. Bertin rjvbertin at gmail.com
Tue Sep 20 19:37:02 UTC 2016


On Tuesday September 20 2016 09:35:57 Thiago Macieira wrote:

>> + #ifdef DBUS_ENABLE_LAUNCHD
>> +       // on Mac we will typically not have all 3 bus addresses; as long
>> +       // as we have the requested one we should be fine.
>> +   if (!init_connections_unlocked () && bus_connection_addresses[type] ==
>> NULL) 

>I don't see how. If I ask for A but B exists, how does that change my 
>predicament?

? You ask for type==A, bus_connection_addresses[type]!=NULL and passes the tests further down in the function. How is that a predicament, and why would we care if the other, unwanted bus types are not available?
NB: this patch allows the expected behaviour.

>You should probably change init_connections_unlocked instead and add a 
>function like init_sessionaddress.

How does this play out on Linux? I haven't yet run a debugger beyond where init_connections_unlocked() starts checking for a session bus address, but got the impression that a missing session bus address situation would be flagged as "we can always create one automatically". Which probably never happens if the client only requests a system bus connection.
And if that's correct, I don't see how my proposal is any different.

Creating a functional session bus address on Mac means asking launchd to start a session bus for the user (root in this case); the session socket (or at least its name) is created by launchd.

Or am I missing something and is there a reason why a session address has to exist when the client wants to connect to the system bus?

Concerning autolaunching a session bus daemon in JIT fashion: that could be DBUS_SESSION_BUS_ADDRESS (or bus_connection_addresses[DBUS_SESSION_BUS]) to something like "launchd:". This address can then be used when a client attempts to connect, to ask launchd to load either the default session-bus plist, or the specified one. I haven't seen anything in the code yet suggesting that the existing "launchd:env=FOO"syntax is used that way.
But I'm not convinced there's a real need for that.

>> 4- KAuth::BackendsManager::helperProxy()->initHelper() calls
>> m_busConnection.registerService() with the service ID.
>
>That only works if you've dropped a root-owned file in /etc/dbus-1/system.d

KAuth clients making use of this feature will of course have to provide one.

R.


More information about the dbus mailing list