This is likely too specific (ActiveConnection/0): + dbus (send) + bus=system + interface="org.freedesktop.DBus.Properties" + path=/org/freedesktop/NetworkManager/ActiveConnection/0 + member=GetAll + peer=(name=org.freedesktop.NetworkManager),
This is too lenient: + dbus (send) + bus=system + interface="org.freedesktop.DBus.Properties" + path=/org/freedesktop/NetworkManager + member=GetAll + peer=(name=org.freedesktop.NetworkManager), The Get*() and Set() methods are precisely what I was talking about before because these methods specify what to get and set based on member arguments and thus cannot be further restriceted by apparmor. In other words, this method allows an app to get any property from network manager, which is far too lenient. Network manager is designed with a different trust model that does not fit within the context of trusted helpers. Namely, network manager relies on policy kit and assumes the user that is able to talk to it (via policy kit ACLs) is trusted. On touch, the app is not trusted but the user is allowed to talk to network manager. Therefore, network manager's current design does not afford itself to opening up its api in the manner requested by this patch. Which gets us back to the several choices: * use connectivity api instead. It was specifically designed for this. apps talk to connectivity api via its simple and safe api, and it talks to network manager. * write a proxy that is able to inspect the member data and filter it accordingly. * patch network manager to provide a safe api for the things apps need connectivity api is implemented precisely to address the concerns in this bug and it seems clear (to me) that we should be using it. The proxy idea would work and other libraries wouldn't have to be patched (much) to use it, but is yet another service, is error prone and the hardest to implement in the short term. Patching network manager requires effort, increases maintenance costs and ultimately the same work for apps to use it as adjusting them to use connectivity api. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor-easyprof-ubuntu in Ubuntu. https://bugs.launchpad.net/bugs/1404188 Title: QNetworkSession::isOpen() always returns false Status in Canonical System Image: Confirmed Status in apparmor-easyprof-ubuntu package in Ubuntu: Confirmed Status in qtbase-opensource-src package in Ubuntu: Confirmed Bug description: Using QNetworkSession::isOpen() in confined apps on a phone running vivid always returns false. This might be an apparmor thing, however, I couldn't find any REJECTED entries in log files. The test app in lp:~mzanetti/+junk/nmsessiontest can reproduce the issue. Open this project in ubuntu-sdk's qtcreator and run it on a vivid device. Press the button and watch the debug prints. On a vivid-desktop or a RTM based phone it will print "all is well". On a vivid phone however, it'll print "network session not open..." This used to work fine at least back in utopic images. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1404188/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
