© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
This is likely too specific (ActiveConnecti
+ dbus (send)
+ bus=system
+ interface=
+ path=/org/
+ member=GetAll
+ peer=(name=
This is too lenient:
+ dbus (send)
+ bus=system
+ interface=
+ path=/org/
+ member=GetAll
+ peer=(name=
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.