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
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
