Re: about using privileged (KAuth) helpers: system dbus daemon on OS X?
René J.V. Bertin <[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <13682732.G2siUGGUL7@bola> |
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. _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus