group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #10106
[Bug 1611444] Re: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP
Marking fix released since 2.20 is available in 16.04 now.
** Changed in: snap-confine (Ubuntu Xenial)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1611444
Title:
Cannot share a namespaces created with 'ip netns' between apps in a
devmode SNAP
Status in Snappy Launcher:
Fix Released
Status in Snappy:
Invalid
Status in snap-confine package in Ubuntu:
Fix Released
Status in snap-confine source package in Xenial:
Fix Released
Bug description:
[Impact]
snap-confine uses linux namespaces (specifically the mount namespace)
to give each started snap application process an isolated an unique
view of the filesystem. This prevented applications using namespaces
through bind mounted files, e.g. using the "ip netns" command as any
changes to the namespace would be "locked" in the unique mount
namespace of each application process.
Now snap-confine is re-designed to put all applications belonging to a
given snap in the same mount namespace. The first started application
creates and persists the mount namespace (in a way similar to running
the command: unshare -m /path/to/file) and all other processes for all
apps in the same snap just join that populated namespace.
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/main
/mount-ns-sharing/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.
Note that this feature affects every application in every snap.
[Regression Potential]
* Regression potential is moderate. This change is large and
intrusive and has managed to uncover bugs in the kernel implementation
of apparmor (e.g. https://bugs.launchpad.net/apparmor/+bug/1624497)
The feature was tested extensively by the upstream developers but
still a potential for unexpected breakage is significant.
[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 # ==
Please see:
https://www.mail-archive.com/snapcraft@xxxxxxxxxxxxxxxx/msg00542.html
for additional details. It was requested that I move that discussion
to this bug report.
In summary it appears that multions "apps" in a SNAP cannot share the
same NETNS namespace. If one app create a namespace the other apps in
SNAP cannot use it. They get assorted errors like:
RTNETLINK answers: Invalid argument
Please see the details in the mail archive posting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snap-confine/+bug/1611444/+subscriptions