** Changed in: qtubuntu-camera (Ubuntu RTM)
Status: Triaged => Invalid
--
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:
Triaged
Status in qtubuntu-camera package in Ubuntu:
Triaged
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
