Allow access to the currently running kernel sources from /usr/src

[Zygmunt Krynicki]

[Impact]

Snaps (even in running in devmode) cannot access the /usr/src directory.

This bug is fixed by adding /usr/src to a list of directories that are bind mounted and thus visible to snaps in their execution environment.

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-1597842/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 the fix simply adds another directory to a list of directories that needs to be bind mounted.

* 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.

* 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 # ==

This issue is a fork of https://bugs.launchpad.net/snap-confine/+bug/1584394

The reported there required access to /usr/src having the sources for the kernel headers.

I think this is something that could be handled by a dedicated interface or perhaps directly with the new content-sharing interface. We would have to be careful on how this works but on classic we could expose /usr/src this way.

[Jamie Strandboge (jdstrand)]

Since I've been looking at interfaces in support of bcc, I looked into this and agree this should be handled in the interfaces for a proper solution. One way to do this would be to allow the .fstab parsing to allow OS/classic mounts somehow instead of just snap mounts, then interfaces could declare what OS/classic mounts to add instead of hard-coding them in snap-confine.

More concretely, rather than unconditionally bind mounting /var/log in snap-confine, the log-observe interface would add an entry to .fstab on interface connect. In this manner, only the snaps that are connected to log-observe get the additional bind mount, which is a cleaner runtime and easier to maintain. The same could be done with /usr/src.

In the meantime for /usr/src however I plan to add /usr/src to the list of OS mounts in snap-confine to unblock the bcc snap, then circle back around and do the above. As such, assigning this bug to me.

[Jamie Strandboge (jdstrand)]

Moving the final solution to bug #1609499. This bug will track mounting /usr/src in the short term.

[Jamie Strandboge (jdstrand)]

This is merged in trunk now.

[Zygmunt Krynicki (zyga)]

I plan to do a new upstream release shortly so this will start to be available to distributors.

[Martin Pitt (pitti)]

Hello Zygmunt, 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)]

The version 1.0.38-0ubuntu0.16.04.10 does contain the apparmor profile but not the bind mount. This was probably a mislabelling as this SRU was intended to fix all of the apparmor denials and simply copied the updated apparmor profile.

As such the apparmor side of this bug is fixed but the main part is not fixed. The main part of this bug is fixed in the 1.0.41 (and beyond) which stops with the cherry picking and updates all of snap-confine to match the tested upstream release code.

[Zygmunt Krynicki (zyga)]

Marking as verification-done per discussion with pitti. This will be updated again with the 1.0.41-0ubuntu0 update.

[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

[Andy Whitcroft (apw)]

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.