** Description changed: + [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://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/regression/lp-1595444/task.yaml + + 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/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 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://wiki.ubuntu.com/SnapdUpdates + + == # 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)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1612684 Title: dies when run in a place that is not inside the snap chroot To manage notifications about this bug go to: https://bugs.launchpad.net/snap-confine/+bug/1612684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
