On Thu, Jun 09, 2016 at 02:27:44PM -0700, Mike Wright wrote: > On 06/09/2016 01:13 PM, Stéphane Graber wrote: > >On Thu, Jun 09, 2016 at 12:56:55PM -0700, Mike Wright wrote: > >>On 06/09/2016 12:40 PM, Stéphane Graber wrote: > >>>Sounds like your host /proc is over-mounted which triggers a protection > >>>mechanism in the kernel that prevents an unprivileged user from mounting > >>>it. > >>> > >>>Look in your host's /proc/mounts for any mountpoint under /proc, try > >>>unmounting them one by one until you find the one that's triggering the > >>>protection. > >> > >>Thanks Stéphane, > >> > >>Here's what's there: > >> > >>grep proc /proc/mounts: > >> > >>proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 > >> > >>systemd-1 /proc/sys/fs/binfmt_misc autofs > >>rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0 > >> > >>xenfs /proc/xen xenfs rw,relatime 0 0 > >> > >>I don't think I can safely remove any of those. Any other ideas? > > > >I don't expect either of use to be in active constant use, so you can > >still try unmounting them temporarily. > > > >An alternative is to mount /proc somewhere else on the host where it's > >not hidden by those mounts. > > > >For example: > > - mkdir /mnt/proc > > - mount -t proc proc /mnt/proc > > Success! > > Created /alt/proc and mounted another proc there. Unprivileged container > started. But I don't understand. > > Don't the multiple procs conflict with each other in any way? How did lxc > find the correct proc to use? > > There were two privileged containers running already without problems, and I > used to run some unprivileged containers with lxc-1. > > Do I just accept this as a new fact of life with lxc and add a mount proc > line to fstab? > > (Sorry for being dimwitted).
It's got nothing to do with LXC. It's a kernel security mechanism. Unprivileged users cannot mount a filesystem which is already mounted and which has paths "hidden" by another mount. So if you just had /proc mounted with nothing on /proc/xen and /proc/sys/fs/binfmt_misc, the kernel would have allowed the container to mount proc just fine. Because you had paths "hidden" from your host's /proc, the kernel prevented the mount as it would have "exposed" the hidden paths to a privileged user. 99% of the time, this check is basically a false positive. Yes, files are hidden by those mounts, but that's perfectly normal and nothing security sensitive is hidden by them. In such case, mounting a new copy of the filesystem (proc in this case) without the over-mounting, makes it so that the unprivileged user owning the container can see the entirety of the filesystem and so the kernel allows it to mount new copies of it. This typically affects proc and sys. It's reasonably rare that it affects containers running directly on the host but it does very frequently (if not always) affect container nesting. Which is why the LXC nesting configuration sets up a clean mount of proc and sys for you. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: PGP signature
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
