Stream tubes have an extensible access control mechanism[1] consisting of an enumerated value for access control type, and a variant for optional parameters. However, D-Bus tubes always use libdbus' default access control, which is to accept exactly those connections that present Unix socket credentials indicating that they're from the same Unix userid as the connection manager itself (equivalent to Socket_Access_Control_Credentials). For future OLPC use, we need to be able to accept connections from a userid that is not the same as that of the connection manager; currently the OLPC packages have a patch to accept connections from *all* userids (equivalent to Socket_Access_Control_Localhost). While we're adding new API for offering D-Bus tubes, we might as well have OfferDBusTube() additionally return the same address that GetDBusTubeAddress() would return for the new tube ID, to save a round-trip. Suggested implementation: OfferDBusTubeWithAccessControl ( s: service, a{sv}: parameters, u: access_control_type, v: access_control_param ) -> u: tube_id, s: dbus_address AcceptDBusTubeWithAccessControl ( u: tube_id, u: access_control_type, v: access_control_param ) -> s: dbus_address For the OLPC bit we also need a new socket access control type, Socket_Access_Control_Unix_User, with the variant containing a UInt32 for the user ID. [1] extensible by the Telepathy spec, rather than by third parties
I think Channel.Type.DBusTube solves this. Fixed in 0.17.something.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.