| 2016-08-11 08:15:47 |
Zygmunt Krynicki |
bug |
|
|
added bug |
| 2016-08-11 08:16:04 |
Zygmunt Krynicki |
snap-confine: milestone |
|
1.0.40 |
|
| 2016-08-11 08:16:08 |
Zygmunt Krynicki |
snap-confine: assignee |
|
Zygmunt Krynicki (zyga) |
|
| 2016-08-11 08:16:10 |
Zygmunt Krynicki |
snap-confine: importance |
Undecided |
High |
|
| 2016-08-11 08:16:14 |
Zygmunt Krynicki |
snap-confine: status |
New |
In Progress |
|
| 2016-08-11 16:06:44 |
Zygmunt Krynicki |
snap-confine: status |
In Progress |
Fix Committed |
|
| 2016-08-12 15:38:02 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-08-12 15:38:04 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2016-08-12 15:38:08 |
Adam Conrad |
tags |
|
verification-needed |
|
| 2016-08-12 15:43:58 |
Adam Conrad |
bug task added |
|
snap-confine (Ubuntu) |
|
| 2016-08-12 15:44:12 |
Adam Conrad |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-08-12 15:44:12 |
Adam Conrad |
bug task added |
|
snap-confine (Ubuntu Xenial) |
|
| 2016-08-12 15:44:23 |
Adam Conrad |
snap-confine (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2016-08-15 07:58:32 |
Michael Vogt |
description |
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories. |
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories.
TEST CASE:
1. sudo snap install bluez
2. sudo systemctl status snap.bluez.obex
3. verify that it fails to start the service
4. install snapd from xenial-proposed
5. snap remove bluez
6. snap install bluez
7. repeat (2)
8. verify that it works this time |
|
| 2016-08-15 13:04:42 |
Launchpad Janitor |
snap-confine (Ubuntu): status |
New |
Confirmed |
|
| 2016-08-15 14:15:16 |
Federico Gimenez |
tags |
verification-needed |
verification-done |
|
| 2016-08-22 11:42:23 |
Zygmunt Krynicki |
snap-confine: status |
Fix Committed |
Fix Released |
|
| 2016-08-23 15:48:08 |
Michael Vogt |
snap-confine (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2016-08-24 13:46:17 |
Launchpad Janitor |
snap-confine (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-08-24 13:46:24 |
Chris J Arges |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-09-20 11:37:19 |
Zygmunt Krynicki |
description |
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories.
TEST CASE:
1. sudo snap install bluez
2. sudo systemctl status snap.bluez.obex
3. verify that it fails to start the service
4. install snapd from xenial-proposed
5. snap remove bluez
6. snap install bluez
7. repeat (2)
8. verify that it works this time |
[Impact]
Snaps cannot access $SNAP_USER_DATA directory because snap-confine des not create it.
This bug is fixed by reverting code that was removed from snap-confine that used to create this directory. This was done because at the time snapd developers introduced a feature where snapd itself would create the appropriate directory but this change took longer to enable than anticipated and in result, for a while, neither program did this.
Now snap-confine tries to create the directory even if snapd also does it earlier. This ensures that in the execution environment the snap application can rely on this directory to be in place.
For more information about the execution environment, please see this article http://www.zygoon.pl/2016/08/snap-execution-environment.html
[Test Case]
The test case can be found here:
https://github.com/snapcore/snap-confine/blob/master/spread-tests/user-data-dir-created/task.yaml
The test case is ran automatically for each pull request and for each final release. It can be reproduced manually by executing the shell commands listed in the prepare/execute/restore phases manually.
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.
[Regression Potential]
* Regression potential is minimal as this code used to exist in snap-confine before.
* The fix was tested on Ubuntu via spread and on several other distributions successfully.
[Other Info]
* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.41.
* This bug was included in an earlier SRU and is now fixed in Ubuntu. I am updating the template here to ensure that the process is fully documented from 1.0.38 all the way up to the current upstream release 1.0.41.
* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates
== # Pre-SRU bug description follows # ==
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories.
TEST CASE:
1. sudo snap install bluez
2. sudo systemctl status snap.bluez.obex
3. verify that it fails to start the service
4. install snapd from xenial-proposed
5. snap remove bluez
6. snap install bluez
7. repeat (2)
8. verify that it works this time |
|
| 2016-09-20 11:37:28 |
Zygmunt Krynicki |
description |
[Impact]
Snaps cannot access $SNAP_USER_DATA directory because snap-confine des not create it.
This bug is fixed by reverting code that was removed from snap-confine that used to create this directory. This was done because at the time snapd developers introduced a feature where snapd itself would create the appropriate directory but this change took longer to enable than anticipated and in result, for a while, neither program did this.
Now snap-confine tries to create the directory even if snapd also does it earlier. This ensures that in the execution environment the snap application can rely on this directory to be in place.
For more information about the execution environment, please see this article http://www.zygoon.pl/2016/08/snap-execution-environment.html
[Test Case]
The test case can be found here:
https://github.com/snapcore/snap-confine/blob/master/spread-tests/user-data-dir-created/task.yaml
The test case is ran automatically for each pull request and for each final release. It can be reproduced manually by executing the shell commands listed in the prepare/execute/restore phases manually.
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.
[Regression Potential]
* Regression potential is minimal as this code used to exist in snap-confine before.
* The fix was tested on Ubuntu via spread and on several other distributions successfully.
[Other Info]
* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.41.
* This bug was included in an earlier SRU and is now fixed in Ubuntu. I am updating the template here to ensure that the process is fully documented from 1.0.38 all the way up to the current upstream release 1.0.41.
* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates
== # Pre-SRU bug description follows # ==
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories.
TEST CASE:
1. sudo snap install bluez
2. sudo systemctl status snap.bluez.obex
3. verify that it fails to start the service
4. install snapd from xenial-proposed
5. snap remove bluez
6. snap install bluez
7. repeat (2)
8. verify that it works this time |
[Impact]
Snaps cannot access $SNAP_USER_DATA directory because snap-confine does not create it.
This bug is fixed by reverting code that was removed from snap-confine that used to create this directory. This was done because at the time snapd developers introduced a feature where snapd itself would create the appropriate directory but this change took longer to enable than anticipated and in result, for a while, neither program did this.
Now snap-confine tries to create the directory even if snapd also does it earlier. This ensures that in the execution environment the snap application can rely on this directory to be in place.
For more information about the execution environment, please see this article http://www.zygoon.pl/2016/08/snap-execution-environment.html
[Test Case]
The test case can be found here:
https://github.com/snapcore/snap-confine/blob/master/spread-tests/user-data-dir-created/task.yaml
The test case is ran automatically for each pull request and for each final release. It can be reproduced manually by executing the shell commands listed in the prepare/execute/restore phases manually.
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.
[Regression Potential]
* Regression potential is minimal as this code used to exist in snap-confine before.
* The fix was tested on Ubuntu via spread and on several other distributions successfully.
[Other Info]
* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.41.
* This bug was included in an earlier SRU and is now fixed in Ubuntu. I am updating the template here to ensure that the process is fully documented from 1.0.38 all the way up to the current upstream release 1.0.41.
* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates
== # Pre-SRU bug description follows # ==
We've noticed that the code that creates the $SNAP_USER_DATA directory has now been removed from snap-confine for the past few releases but the corresponding code in snapd, that depends on snap-exec, is not yet active. This has lead to some snaps that rely on it to have no way to create per-user data directories.
TEST CASE:
1. sudo snap install bluez
2. sudo systemctl status snap.bluez.obex
3. verify that it fails to start the service
4. install snapd from xenial-proposed
5. snap remove bluez
6. snap install bluez
7. repeat (2)
8. verify that it works this time |
|
