Allow access to the currently running kernel sources from /usr/src
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snappy |
Invalid
|
Undecided
|
Unassigned | ||
snap-confine |
Fix Released
|
High
|
Jamie Strandboge | ||
snap-confine (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[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://
[Test Case]
The test case can be found here:
https:/
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 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:/
== # Pre-SRU bug description follows # ==
This issue is a fork of https:/
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.
tags: | added: snapd-interfaces |
Changed in snap-confine: | |
status: | New → Confirmed |
Changed in snappy: | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
Changed in snap-confine: | |
importance: | Undecided → Wishlist |
Changed in snap-confine: | |
milestone: | none → 1.0.40 |
Changed in snap-confine: | |
status: | Fix Committed → Fix Released |
description: | updated |
description: | updated |
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.