snap-confine prevented from mounting base directory through the "content" interface
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snap-confine |
Fix Released
|
High
|
Zygmunt Krynicki | ||
snap-confine (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
The "content" interface refused to share the entire contents of one snap with another snap.
This bug was caused by overzealous confinement of snap-confine itself that required for the "source" of the sharing to be a sub-directory of a snap. This restriction was lifted by editing the apparmor profile for snap-confine.
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 makes the apparmor confinement of snap-confine slightly less restrictive.
[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 # ==
Using the new "content" interface, and following the integration tests as an example, I have build two snaps in https:/
Both build, install, and connect just fine, but on trying to run /snap/bin/geany it immediately fails with the following message:
cannot mount /snap/geany-
Checking dmesg after this shows the following:
[335489.022097] audit: type=1400 audit(147162499
I belive this is due to the fact that my geany-plugins slot is sharing the root of it's content (/) instead of a file or folder by name. This makes the mount source /snap/geany-
To test this, I made the following change to /etc/apparmor.
120,121c120,121
< mount options=(rw bind) /snap/*/*/** -> /snap/*/*/**,
< mount options=(ro bind) /snap/*/*/** -> /snap/*/*/**,
---
> mount options=(rw bind) /snap/*/** -> /snap/*/*/**,
> mount options=(ro bind) /snap/*/** -> /snap/*/*/**,
This allowed the mount to happen and the application to run.
summary: |
- snap-confine prevented from mounting directories shared through the + snap-confine prevented from mounting base directory through the "content" interface |
Changed in snap-confine: | |
status: | In Progress → Fix Committed |
Changed in snap-confine: | |
status: | Fix Committed → Fix Released |
description: | updated |
Changed in snap-confine (Ubuntu): | |
status: | Confirmed → Fix Released |
This is addressed with the following pull request: https:/ /github. com/snapcore/ snap-confine/ pull/113