| 2013-09-25 15:47:14 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2013-09-25 15:47:26 |
Jamie Strandboge |
touch-preview-images: assignee |
|
Ricardo Salveti (rsalveti) |
|
| 2013-09-25 15:48:19 |
Jamie Strandboge |
tags |
|
application-confinement |
|
| 2013-09-25 15:59:09 |
Matthew Paul Thomas |
bug |
|
|
added subscriber Matthew Paul Thomas |
| 2013-09-25 16:41:00 |
Jamie Strandboge |
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.
This should be implemented in time for shippable devices to address the application confinement concern. |
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. |
|
| 2014-05-02 18:07:40 |
Jim Hodapp |
touch-preview-images: assignee |
Ricardo Salveti (rsalveti) |
Jim Hodapp (jhodapp) |
|
| 2014-05-02 18:07:46 |
Jim Hodapp |
touch-preview-images: importance |
Undecided |
High |
|
| 2014-05-02 18:07:51 |
Jim Hodapp |
touch-preview-images: status |
New |
Triaged |
|
| 2014-06-13 18:33:34 |
Jamie Strandboge |
bug task added |
|
qtubuntu-camera (Ubuntu) |
|
| 2014-06-13 18:33:44 |
Jamie Strandboge |
qtubuntu-camera (Ubuntu): status |
New |
Triaged |
|
| 2014-06-13 18:33:46 |
Jamie Strandboge |
qtubuntu-camera (Ubuntu): importance |
Undecided |
High |
|
| 2014-06-13 18:33:57 |
Jamie Strandboge |
qtubuntu-camera (Ubuntu): assignee |
|
Jim Hodapp (jhodapp) |
|
| 2014-06-17 14:22:58 |
Jamie Strandboge |
tags |
application-confinement |
application-confinement rtm14 |
|
| 2014-07-01 16:07:28 |
Bill Filler |
bug task deleted |
touch-preview-images |
|
|
| 2014-07-31 14:33:57 |
Jamie Strandboge |
qtubuntu-camera (Ubuntu): importance |
High |
Critical |
|
| 2014-09-25 15:51:52 |
Jim Hodapp |
tags |
application-confinement rtm14 |
application-confinement ota-1 touch-2014-10-23 |
|
| 2015-06-28 20:19:34 |
Matthew Paul Thomas |
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. |
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..." |
|
| 2015-07-02 12:51:18 |
Matthew Paul Thomas |
tags |
application-confinement ota-1 touch-2014-10-23 |
application-confinement lorcha ota-1 touch-2014-10-23 |
|
| 2015-07-14 17:05:28 |
John McAleely |
qtubuntu-camera (Ubuntu): assignee |
Jim Hodapp (jhodapp) |
|
|
| 2015-07-14 17:05:41 |
John McAleely |
bug task added |
|
canonical-devices-system-image |
|
| 2015-07-14 17:05:44 |
Jim Hodapp |
bug task added |
|
qtubuntu-camera (Ubuntu RTM) |
|
| 2015-07-14 17:05:50 |
John McAleely |
canonical-devices-system-image: assignee |
|
John McAleely (john.mcaleely) |
|
| 2015-07-14 17:05:59 |
John McAleely |
canonical-devices-system-image: milestone |
|
ww34-2015 |
|
| 2015-07-14 17:06:04 |
Jim Hodapp |
qtubuntu-camera (Ubuntu RTM): status |
New |
Triaged |
|
| 2015-07-14 17:06:09 |
Jim Hodapp |
qtubuntu-camera (Ubuntu RTM): importance |
Undecided |
Critical |
|
| 2015-07-14 17:06:15 |
Jim Hodapp |
canonical-devices-system-image: status |
New |
Confirmed |
|
| 2015-07-14 17:10:04 |
John McAleely |
canonical-devices-system-image: importance |
Undecided |
High |
|
| 2015-07-14 17:10:09 |
John McAleely |
canonical-devices-system-image: status |
Confirmed |
Triaged |
|
| 2015-07-15 08:56:34 |
John McAleely |
qtubuntu-camera (Ubuntu RTM): status |
Triaged |
Invalid |
|
| 2015-07-15 08:57:31 |
Manuel de la Peña |
canonical-devices-system-image: assignee |
John McAleely (john.mcaleely) |
Manuel de la Peña (mandel) |
|
| 2015-07-15 08:57:34 |
Manuel de la Peña |
qtubuntu-camera (Ubuntu): assignee |
|
Manuel de la Peña (mandel) |
|
| 2015-07-15 08:57:38 |
Manuel de la Peña |
qtubuntu-camera (Ubuntu RTM): assignee |
|
Manuel de la Peña (mandel) |
|
| 2015-07-31 19:01:13 |
Pat McGowan |
canonical-devices-system-image: assignee |
Manuel de la Peña (mandel) |
John McAleely (john.mcaleely) |
|
| 2015-08-14 15:14:01 |
John McAleely |
canonical-devices-system-image: status |
Triaged |
In Progress |
|
| 2015-08-14 16:51:32 |
John McAleely |
canonical-devices-system-image: importance |
High |
Critical |
|
| 2015-08-19 14:41:41 |
John McAleely |
bug task added |
|
android (Ubuntu) |
|
| 2015-08-19 14:41:53 |
John McAleely |
android (Ubuntu): status |
New |
Fix Released |
|
| 2015-08-19 14:42:04 |
John McAleely |
qtubuntu-camera (Ubuntu): status |
Triaged |
Invalid |
|
| 2015-08-19 14:42:12 |
John McAleely |
qtubuntu-camera (Ubuntu): assignee |
Manuel de la Peña (mandel) |
|
|
| 2015-08-19 14:42:15 |
John McAleely |
qtubuntu-camera (Ubuntu RTM): assignee |
Manuel de la Peña (mandel) |
|
|
| 2015-08-26 09:42:14 |
Bill Filler |
canonical-devices-system-image: status |
In Progress |
Fix Committed |
|
| 2015-08-31 15:17:30 |
Pat McGowan |
canonical-devices-system-image: status |
Fix Committed |
Fix Released |
|
