dies when run in a place that is not inside the snap chroot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snap-confine |
Fix Released
|
Undecided
|
Zygmunt Krynicki | ||
snap-confine (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Snap applications would refuse to run if the current working directory was impossible to preserve across the chroot that snap-confine performs internally.
This was somewhat annoying and surprising to various users so it was changed to a more graceful failure mode where snap-confine would change the working directory to /var/lib/snapd/void that has permissions 0000. This results in applications working gracefully as long as they don't care about the current directory. If they do they also fail gracefully by just being unable to access anything in that directory.
The fix involves just doing a chdir() to /var/lib/snapd/void and appropriate packaging changes to ensure that it has the correct permissions.
For more information about the execution environment, please see this article http://
[Test Case]
The test case can be found here:
https:/
NOTE: the bug number above is different as the desired design changed during the release.
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/
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.
[Regression Potential]
* Regression potential is small as the previous behaviour was unexpected (applications would just fail to start) and now they will start but perhaps the current working directory will be changed.
* 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:/
== # Pre-SRU bug description follows # ==
When running any snap from a place that is not inside the snap chroot (like /tmp/some-subdir or /srv) running the snap-confine launcher dies with a ugly error.
TEST CASE:
1. mkdir /tmp/99
2. cd /tmp/99
3. sudo snap install hello-world
4. verify that it shows: "cannot remain in /tmp/99, please run this snap from another location. errmsg: No such file or directory"
5. install snap-confine from xenial-proposed
6. verify that hello-world runs now (and shows a message that it switches to /tmp)
description: | updated |
Changed in snap-confine: | |
status: | Fix Committed → Fix Released |
Changed in snap-confine (Ubuntu Xenial): | |
status: | Fix Released → Fix Committed |
description: | updated |
Hello Michael, or anyone else affected,
Accepted snap-confine into xenial-proposed. The package will build now and be available at https:/ /launchpad. net/ubuntu/ +source/ snap-confine/ 1.0.38- 0ubuntu0. 16.04.8 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https:/ /wiki.ubuntu. com/Testing/ EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed. In either case, details of your testing will help us make a better decision.
Further information regarding the verification process can be found at https:/ /wiki.ubuntu. com/QATeam/ PerformingSRUVe rification . Thank you in advance!