** Description changed: + [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
** Description changed: [Impact] - Snaps cannot access $SNAP_USER_DATA directory because snap-confine des + 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- + * 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1612120 Title: $SNAP_USER_DATA is no longer created by snap-confine but is not yet created by snapd To manage notifications about this bug go to: https://bugs.launchpad.net/snap-confine/+bug/1612120/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
