touch-packages team mailing list archive

[John McAleely <john.mcaleely@xxxxxxxxxxxxx>]

(#8 has been followed up on the bug mentioned. In short: yes)

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

Title:
  Please provide Ubuntu camera service that integrates with trust-store

Status in Canonical System Image:
  In Progress
Status in android package in Ubuntu:
  Fix Released
Status in qtubuntu-camera package in Ubuntu:
  Invalid
Status in qtubuntu-camera package in Ubuntu RTM:
  Invalid

Bug description:
  Currently Ubuntu Touch is using the android camera-service and that is
  the plan for 13.10.

  Going forward in 14.04, the android camera-service will no longer be
  used and camera access is going to move to the Ubuntu side. There was
  discussion of either using HAL directly (direct access to devices) or
  using a camera-service type thing in Ubuntu.

  Using devices directly causes at least a few problems:
   * can't prevent more than one user from accessing the device at a time
   * enumerating camera devices for apparmor policy is extra maintenance for porters
   * can't provide a contextual runtime prompt for access (like we (will) do with online accounts, location, microphone). This is particularly important for application confinement.

  Instead of direct hardware access, an out of process helper (in
  relation to the app) can be used to address all of these problems,
  similar to what pulseaudio does for audio. This service can ensure
  only one user can access the device at a time and since the service
  accesses the the device files on the app's behalf, we don't need to
  enumerate devices in /dev in policy. Furthermore, when an app accesses
  the service (ideally over DBus), the service can contact trust-store,
  the trust-store will prompt the user ("Foo wants to access the camera.
  Is this ok? Yes|No"), then optionally cache the result and return the
  result to the service. In this manner the user is given a contextual
  prompt at the time of access by the app. By using caching this
  decision can be remembered the next time. If caching is used, there
  should be a method to change the decision in system settings.

  If direct hardware access is needed for performance reasons, it is
  possible to use fd delegation in AppArmor and have the service open
  the device and pass the fd to the app without having to enumerate the
  /dev devices. Please talk to jjohansen if pursuing this option.

  Lastly, bug #1230391 discusses providing a visual cue during
  background recording for audio. We will need to do the same for video
  recording. Feel free to add a task to bug #1230391 if there is work to
  integrate this new service with that visual cuing.

  This should be implemented in time for shippable devices to address
  the application confinement concern.

  <https://wiki.ubuntu.com/AccountPrivileges#permission-prompt>: "On the
  phone, if an app tries to access your ... camera ... or video
  recording, this should be subject to permission..."

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1230366/+subscriptions