[lxc-users] Establish a bind mount to a running container

[Stéphane Graber]

On Fri, Oct 07, 2016 at 02:39:44PM +0200, Wolfgang Bumiller wrote:
> 
> > On October 7, 2016 at 11:45 AM Stéphane Graber <stgraber at ubuntu.com> wrote:
> > 
> > 
> > On Fri, Oct 07, 2016 at 07:03:21AM +0000, Jäkel, Guido wrote:
> > > Dear experts,
> > > 
> > > I wonder if it's possible to establish a bind mount filesystem resource from the LXC host to an already running container in an manual way, but analogous as it is done at startup time. 
> > > 
> > > I already figured out that the releasing an existing link is no thing; just umount it from inside the container. But is there a way to establish one while shifting the destination of a bind mount into the right namespace?
> > > 
> > > I ask about, because in a couple of days I have to change a (NFS) filesystem source (because of an hardware migration) that is common to a large number of running containers but not frequently used and I want to avoid to restart all the containers with it services.
> > > 
> > > thank you for advice
> > > 
> > > Guido
> > 
> > It's very difficult due to a number of restrictions in place in the kernel.
> > 
> > The only way of doing this that I'm aware of is what we do in LXD. We
> > create a path on the host before the container starts, put that on a
> > rshared mountpoint, then bind-mount that directory into the container
> > under some arbitrary path.
> 
> But the container can break this from the inside by turning the inner
> slave mount point into a private mountpoint once (which cannot be undone).
> Then again, the standard AppArmor profile still has the make-private
> on ** rules commented out with the note that AppArmor treats it as
> allowing all mounts, so I suppose in the default case it'll be hard to
> break this functionality.
> 
> I've been wondering if there's a more reliable way for a while now...


You're correct that the container can absolutely break this. Luckily
we've not seen any distribution breaking this by default :)

LXD bypasses the apparmor problem by manually attaching to the mnt and
user namespaces of the container, but to nothing else, so the mount
creation in the container effectively happens outside of apparmor
confinement.


As for alternatives, I tried a few, but they'd all ultimately hit the
bit of kernel code which checks that the source and target mntns of a
new mount matches. Inheriting the mount is the only way I could find to
bypass that particular check.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20161007/c8a8b0ad/attachment.sig>