Quoting Wolfgang Bumiller ([email protected]): > > > On November 11, 2015 at 5:07 PM Serge Hallyn <[email protected]> > > 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? > _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
