** Also affects: snap-confine (Ubuntu)
** Changed in: snap-confine (Ubuntu)
Status: New => Fix Released
** Also affects: snap-confine (Ubuntu Xenial)
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
pivot_root or mounts setup breaks unshare of userns
Status in Snappy Launcher:
Status in snap-confine package in Ubuntu:
Status in snap-confine source package in Xenial:
Snap-Confine uses pivot_root internally. The particular way in which
this is done is somewhat tricky and in effect we used to "leak" the
old root filesystem. This caused the kernel to assume our process is
unsafe and cannot use user namespaces.
The fix includes using unmount2(2) with MNT_DETACH to detach/unmount
the old root filesystem.
For more information about the execution environment, please see this
The test case can be found here:
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 is minimal. Experienced member of the LXD
development team (Stephane Graber) has reported this issue and
recommended the fix that we've applied. The same approach is used by
* The fix was tested on Ubuntu with spread, successfully.
* 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
== # Pre-SRU bug description follows # ==
Starting around the time ubuntu-core-launcher was transitioned to
snap-confine, unsharing a user namespace became impossible.
This is obviously a pretty big deal for LXD.
I've confirmed that this isn't apparmor, seccomp or capabilities
getting in the way and I think I tracked it down to a poor
implementation of the chroot/pivot_root feature in snap-confine.
There is no code in snap-confine to umount the paths outside of the
pivot target. This means the snap mount table then contains a whole
lot of unreachable mounts which will be stuck there forever.
This causes us to trip the chroot detection code in the kernel as
there are more than one root mount point and a ton of completely
unreachable mount entries which makes the kernel think we're in an
unsafe environment for a user namespace to be created.
Strace of the current launcher to a basic binary (lxd --help):
The mount table for a running LXD process is now:
This is also very wasteful, especially considering that snap-confine
creates a new namespace for every single command but more importantly,
it's going to create a bunch of weird issues on systems using snapd,
including potential data loss.
That's because not unmounting unused mount entries (anything outside
of your pivot dir), keeps an active reference to them in the kernel.
This effectively means that none of those mounts can really be
unmounted on the host. The host mount entry will disappear on umount,
but attempting to mount again will fail with "already mounted".
It also means that any non-persistent device (USB stick) will never
get properly unmounted which may cause data loss.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp