> 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. > 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? 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
