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

[René J.V. Bertin]

On Monday September 19 2016 14:44:09 Thiago Macieira wrote:

Below is the sequence of actions as far as I have been able to follow them, when the privileged helper service is started through dbus-daemon-helper-tool. I hope this is detailed enough for someone to say something about how the DBus connection sequence is supposed to play out so.

In the meantime I think I understand where the connection process aborts on OS X: in init_connections_unlocked() (called from internal_bus_get()) when there is no address for neither DBUS_BUS_STARTER nor for DBUS_BUS_SESSION. This is considered an error by internal_bus_get() even if it is asked to get the DBUS_BUS_SYSTEM. 

Would this be an acceptable modification to internal_bus_get()?

+ #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)
+ #else
   if (!init_connections_unlocked ())
+ #endif
     {
       _DBUS_SET_OOM (error);
       goto out;
     }

>On segunda-feira, 19 de setembro de 2016 23:31:28 PDT René J.V. Bertin wrote:
>> I can only suggest you look at the KAuth code (without expecting you to, of
>I'm not going to read its source, sorry.

1- the service exec's main hands over control to KAuth::HelperSupport::helperMain() which creates a QCoreApplication(argc,argv) instance and then calls KAuth::BackendsManager::helperProxy()->initHelper(QString(<service ID>))

2- KAuth::BackendsManager::helperProxy() returns a KAuth::DBusHelperProxy instance; its ctor initialises a member variable m_busConnection=QDBusConnection::systemBus() . So the service exec is indeed supposed to connect to the system dbus, explicitly.

3- KAuth::BackendsManager::helperProxy()->initHelper() creates a new Kf5authAdaptor() which inherits QDBusAbstractAdaptor and sets autoRelaySignals=true . 

4- KAuth::BackendsManager::helperProxy()->initHelper() calls m_busConnection.registerService() with the service ID.

Am I right that qdbus and qdbusViewer also use QDBusConnection::systemBus() to connect to the system bus? I've traced the flow down from that function to a call q_dbus_bus_get_private(DBUS_BUS_SYSTEM, error) which led me into init_connections_unlocked() as described above.

The Kf5AuthAdaptor class is generated with qdbusxml2cpp from a file containing the following:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
    <interface name="org.kde.kf5auth">
        <method name="performAction" >
            <arg name="action" type="s" direction="in" />
            <arg name="callerID" type="ay" direction="in" />
            <arg name="arguments" type="ay" direction="in" />
            <arg name="r" type="ay" direction="out" />
        </method>
        <method name="authorizeAction" >
            <arg name="action" type="s" direction="in" />
            <arg name="callerID" type="ay" direction="in" />
            <arg name="r" type="u" direction="out" />
        </method>
        <method name="stopAction" >
            <arg name="action" type="s" direction="in" />
            <annotation name="org.freedesktop.DBus.Method.NoReply" value="true"/>
        </method>
        <signal name="remoteSignal" >
            <arg name="type" type="i" />
            <arg name="action" type="s" />
            <arg name="blob" type="ay" />
        </signal>
    </interface>
</node>

If and when justified (= as more than a programming exercise) I might implement a KAuth::MacHelperProxy to replace KAuth::DBusHelperProxy on Mac. What makes this more than a trivial matter is the fact that the class implements a whole IPC protocol based on signals/slots which includes calling slots with service-specific names with service-specific argument lists. 

R.