group.of.nepali.translators team mailing list archive

[Michael Hudson-Doyle <michael.hudson+lp@xxxxxxxxxxxxx>]

** Also affects: snap-confine (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: snap-confine (Ubuntu)
       Status: New => Fix Released

** Also affects: snap-confine (Ubuntu Xenial)
   Importance: Undecided
       Status: New

-- 
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:
  New

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