dies when run in a place that is not inside the snap chroot

[Michael Vogt]

[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)

[Adam Conrad (adconrad)]

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/PerformingSRUVerification . Thank you in advance!

[Federico Gimenez (fgimenez)]

Works with latest snap-confine:

fgimenez@innsmouth:~$ apt-cache policy snap-confine
snap-confine:
  Installed: 1.0.38-0ubuntu0.16.04.8
  Candidate: 1.0.38-0ubuntu0.16.04.8
  Version table:
 *** 1.0.38-0ubuntu0.16.04.8 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.38-0ubuntu0.16.04.4 500
        500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
fgimenez@innsmouth:~$ mkdir /tmp/99
fgimenez@innsmouth:~$ cd /tmp/99
fgimenez@innsmouth:/tmp/99$ sudo snap install hello-world
0 B / 20.00 KB [___________________________________________________________________________________________________________________________________________________________________________________] 0.00 %

Name Version Rev Developer Notes
hello-world 6.3 27 canonical -
fgimenez@innsmouth:/tmp/99$ hello-world
hello-world hello-world.env hello-world.evil hello-world.sh
fgimenez@innsmouth:/tmp/99$ hello-world
cannot remain in /tmp/99, moved to /tmp
Hello World!
fgimenez@innsmouth:/tmp/99$

[Zygmunt Krynicki (zyga)]

This is fixed in master with this patch:

https://github.com/snapcore/snap-confine/commit/1ab8e095195d07c766f75f85d9d9430a0f088dbd

It will be released as a part of snap-confine 1.0.40

[Michael Vogt (mvo)]

This is fixed with the 1.0.40 upload to yakkety

[Launchpad Janitor (janitor)]

This bug was fixed in the package snap-confine - 1.0.38-0ubuntu0.16.04.8

---------------
snap-confine (1.0.38-0ubuntu0.16.04.8) xenial; urgency=medium

  * debian/patches/04_not_die_unknown_locations.patch:
    - move to /tmp if the current location can not be preserved
      (LP: #1612684)

snap-confine (1.0.38-0ubuntu0.16.04.7) xenial; urgency=medium

  * fix apparmor rules when a snap is run on new-style encrypted
    home with sudo (LP: #1612291)

snap-confine (1.0.38-0ubuntu0.16.04.6) xenial; urgency=medium

  * fix apparmor rules when a snap is run on encrypted home
    with sudo (LP: #1612291)

snap-confine (1.0.38-0ubuntu0.16.04.5) xenial; urgency=medium

  * 03_fix_snap_user_data_regression.patch:
    - fix regression in autopkgtest with snap-confine when the
      SNAP_USER_DATA directory is not created for services
      (LP: #1612120)

 -- Michael Vogt <email address hidden> Fri, 12 Aug 2016 16:45:17 +0200

[Chris J Arges (arges)]

The verification of the Stable Release Update for snap-confine has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Chris J Arges (arges)]

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.9 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/PerformingSRUVerification . Thank you in advance!

[Martin Pitt (pitti)]

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.10 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/PerformingSRUVerification . Thank you in advance!

[Zygmunt Krynicki (zyga)]

I just verified this on a Xenial VM, following this process https://wiki.ubuntu.com/QATeam/PerformingSRUVerification

The pre-update version contained a small change that moved the process to /tmp instead of exiting. With the update installed the process was correctly moved to /var/lib/snapd/void.

[Zygmunt Krynicki (zyga)]

For the record: the tested version was 1.0.38-0ubuntu0.16.04.10

[Launchpad Janitor (janitor)]

This bug was fixed in the package snap-confine - 1.0.38-0ubuntu0.16.04.10

---------------
snap-confine (1.0.38-0ubuntu0.16.04.10) xenial; urgency=medium

  * debian/usr.lib.snapd.snap-confine:
    - synchronize apparmor profile with upstream 1.0.40 release.
    (LP: #1597842, LP: #1615113, LP: #1584456)

snap-confine (1.0.38-0ubuntu0.16.04.9) xenial; urgency=medium

  * debian/patches/04_not_die_unknown_locations.patch:
    - move to /var/lib/snapd/void (with mode 0) if the current
      location cannot be preserved (LP: #1612684)

 -- Zygmunt Krynicki <email address hidden> Wed, 24 Aug 2016 20:31:12 +0200