touch-packages team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

Marking as "Won't Fix" for qtsystems-opensource-src since there is now a
connectivity-api that apps can use.

** Changed in: qtsystems-opensource-src (Ubuntu Trusty)
       Status: Confirmed => Won't Fix

** Changed in: qtsystems-opensource-src (Ubuntu)
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtsystems-opensource-src
in Ubuntu.
https://bugs.launchpad.net/bugs/1226844

Title:
  QtSystemInfo fails when using ofono and there are DBus denials to
  ofono

Status in “qtsystems-opensource-src” package in Ubuntu:
  Won't Fix
Status in “qtsystems-opensource-src” source package in Saucy:
  Won't Fix
Status in “qtsystems-opensource-src” source package in Trusty:
  Won't Fix

Bug description:
  = Background =
  Applications in the Ubuntu appstore are packaged as click packages and run under confinement. Applications sometimes need to know if they are connected to the internet, on an expensive connection or disconnected. QtSystemInfo::NetworkInfo (via qtdeclarative5-systeminfo-plugin) provides this information to QML applications.

  Attached is a simple QML application to test this and an apparmor
  profile. Save the qml file as /tmp/test-network.qml and the apparmor
  profile as /tmp/profile.

  In one terminal, run:
  $ tail -f /var/log/syslog | grep DEN

  In another, run:
  $ sudo apparmor_parser -r /tmp/profile && aa-exec -p test-network -- qmlscene /tmp/test-network.qml

  On a desktop system, the application should say that it is connected to the home network (or similar) and there will be no apparmor denials for NetworkManager (there will be one for GConf, but that can be ignored). On a system with a working ofono (eg, Nexus 4 with up to date Ubuntu Touch), this the application will report an error. For the error to go away, the following ofono rules must be added to the apparmor profile:
  # ofono
  dbus (send)
       bus=system
       path=/
       interface=org.ofono.Manager
       member=GetModems
       peer=(name=org.ofono),
  dbus (send)
       bus=system
       path=/ril_*
       interface=org.ofono.NetworkRegistration
       member=GetProperties
       peer=(name=org.ofono),
  dbus (receive)
       bus=system
       path=/ril_*
       interface=org.ofono.NetworkRegistration
       member=PropertyChanged
       peer=(name=org.freedesktop.DBus),

  Then rerun 'sudo apparmor_parser -r /tmp/profile && aa-exec -p test-
  network -- qmlscene /tmp/test-network.qml' and the application works
  correctly. Unfortunately, giving access to
  org.ofono.NetworkRegistration.GetProperties reveals far too much
  information to confined applications.

  On the desktop system, /proc and /sys entries are consulted to see if
  online, but on a system with ofono, this is not enough. Ideally we
  would provide a simple dbus service (I think 'uconnectd' would be a
  great name-- feel free to use it ;) with methods like OnlineWired,
  OnlineWireless and OnlineCostlyNetwork. This dbus service would
  consult network manager and ofono, we could declare a simple QML
  plugin as the correct way to check for connectivity.

  Right now, apparmor policy (correctly) denies access to ofono over
  DBus, but applications are unable to determine if they are on the
  network using standard APIs. To fix this in the short term, we can
  adjust to use what is in /proc and /sys and not throw an error if it
  gets an apparmor denial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1226844/+subscriptions