Thread Previous • Date Previous • Date Next • Thread Next |
On 09/17/2013 06:33 PM, Jamie Strandboge wrote:
On 09/12/2013 05:21 PM, Jamie Strandboge wrote:On 08/01/2013 08:23 AM, Jamie Strandboge wrote:On 08/01/2013 05:23 AM, Iain Lane wrote:On Wed, Jul 31, 2013 at 05:42:43PM +0100, Iain Lane wrote:On Wed, Jul 31, 2013 at 03:18:27PM +0400, Alberto Mardegan wrote:On 07/30/2013 07:50 PM, Iain Lane wrote:
<SNIP>
Along these lines-- we really need to define and document the canonical way for determining network accessibility. My team is tasked with defining apparmor policy for this, and SDK app developers should ideally do this one way and then my team can write tests to make sure that it works for that use case. Everyone coming up with their own method won't work with application confinement.I looked into this a bit today. We should *not* rely on anything that uses network-manager to obtain this information. Its DBus API does not currently provide the answer to "Can I use the internet?" without granting a whole bunch of other accesses.
So it seems like we're stuck, we can't easily use NM without granting too much access, and we can't use qtdeclaritive5-systeminfo-plugin because it requires opening up the ofono DBus APIs, potentially revealing too much information.
Sounds like a bit of a catch-22 to me.That said, I'm leery about your suggestion to provide a new DBus service in order to provide this information to the app framework. Although it seems like a simple concept, it'd be yet another daemon running on the system who's purpose is to proxy information available from another system daemon ( or daemons ). NM should have the information and the means to acess the information. I woudl think we'd be able to fix what really sounds to me like an access control problem.
Looking at your description in LP: #1226844 it seems that AppArmor allows access control at the DBus interface member ( ie. method name ) level. Wouldn't it be possible to open up the required NM methods for qtdeclaritive5-systeminfo-plugin to be able to determine online state, active interface, ...?
Note, you didn't actually say however that qtdeclaritive5-systeminfo-plugin has code to talk to NM, so there's a chance that this code would need to be written.
Instead, apps should use qtdeclarative5-systeminfo-plugin, specifically NetworkInfo[1]. I played with this today and rather than talking to network-manager, it just reads various files in /sys, /proc and needs 'inet stream' and 'inet dgram'. I'll be updating the apparmor policy group for 'connectivity' to allow these accesses so it works with qtdeclarative5-systeminfo-plugin. I also tested (a bit) with C++ using QHostAddress and QNetworkInterface.
Hmmm, so for some things the plugin goes to /proc and /sys, and for others it bails and uses a DBus API. I would think we'd be better off having it querying a single source (NM in this case).
Regards, /tony
Thread Previous • Date Previous • Date Next • Thread Next |