[lxc-users] pre-mount hook namespace

[Serge Hallyn]

Quoting Wolfgang Bumiller (w.bumiller at proxmox.com):
> 
> > On November 11, 2015 at 5:07 PM Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > Mount a filesystem for the unprivileged user which the they cannot
> > > mount by themselves due to a lack of permissions.
> > > # mount -o loop /path/you/don't/have/access/to.img /the/container
> > 
> > A few things,
> > 
> > 1.
> > If you just want this to be a container in a user namespace, you could
> > pre-mount it to a path where the user does have access so they can use
> > a regular lxc.mount.entry.
> 
> Yes I know. I was just wondering if I can avoid having to mount it in
> the host's namespace.
> 
> > 2.
> > If you are just using unpriv containers to use user namespaces, you can
> > actually have the container be owned/started by root.  That's what I do
> > for some containers where their rootfs is a dmcrypt device which I
> > couldn't mount as an unpriv user.
> 
> They are started as root, which means I can prepare the mounts as you
> suggested above, but I'd again be clobbering the host's namespace.

Oh, right.  I forget that even when starting as root, this only works
for the rootfs itself, not other mounts.  (Lxd actually does handle this,
but at the cost of having a MS_SLAVE mount per container)

> > 3.
> > Seth Forshee is working on support for several things that would help you
> > here - in particular unprivileged users mounting ext4, using loop devices,
> > and fuse.  Doesn't help you right now, but soon it might.
> 
> Sounds interesting, but not all our storage backends use loop devices
> (or are ext4 (eg a zfs subvolume...)).
> Btw. does that imply giving access to a loop device to the container's
> user?

No, I think it will be a new loop pseudofs akin to devpts.  So the
unpriv user won't be able to use the host's /dev/loop0, rather he'll
mount a new instances of loopfs which will have loop devices private
to his namespace.

> Because this can be problematic. At least if the user can unmount
> and detach the loop device. They could then wait for the next victim
> to reuse it (with the next `mount -o loop` etc.) Just something to
> look out for. Unless you can forbid the detaching. Seccomp maybe?
>