Quoting Dan Fandrich (d...@coneharvesters.com): > On Mon, Jan 13, 2014 at 06:23:24PM -0600, Serge Hallyn wrote: > > Gah, that really does suck, sorry. The need to run as root has always > > been annoying. We're finally at the point that some containers can be > > created and run entirely as non-root, so that your host should be a lot > > safer. > > That's definitely a positive development! > > > > This was with lxc 0.8.0 on x86 Linux (the relevant 0.9.0 code looks > > > substantially similar). It happened shortly after installing lxc for the > > > first > > > time to try it out. I believe what must have happened was that the > > > container I > > > created wasn't shut down properly and still had its bind mounts for /lib > > > etc. > > > > lxc-start would not have done any mounting in the host's mount > > namespace, so that scenario shouldn't be possible. > > > > So I would actually guess that lxc-create (actually the template) was to > > blame for leaving the bind mounts. Since it looks like you're not using > > a stock template I'm not sure how you created the container. > > That's quite possible; I'm not completely sure yet how all the lxc > moving parts fit together yet. I was using the stock busybox template, but > there were a couple of configuration problems with lxc, so it wasn't a single > perfectly clean create/start/stop. > > > > in place. The container must have been down enough to be considered not > > > running > > > according to lxc-info, so lxc-destroy helpfully rm -rf'ed it, including > > > the > > > contents of the bind mounts which pointed into my host system. > > > > > > rm was given the --one-file-system option, but it didn't prevent this from > > > occurring, presumably because the device ID of the container location was > > > the > > > same as the device ID of the /lib of the host. After looking at the > > > source to > > > lxc-destroy, I'm surprised this kind of problem doesn't happen more > > > often--it > > > > We do discourage bind-mounting from the host fs into the container, but > > historcally it was considered useful (and may again) for checkpoint/restart. > > > > > is not at all defensively written (error codes ignored, arguments not > > > properly > > > quoted, this problem I'm writing about, etc.), so I was glad to see that > > > lxc-destroy has since been reimplemented. However, on briefly looking at > > > the > > > new source, it seems that the same problem can still occur. There's a > > > comparison of device IDs before deleting files (presumably, to try to > > > accomplish the same thing as rm's --one-file-system option), but my > > > situation > > > of bind mounts on the same filesystem device means once again that > > > wouldn't be > > > effective in preventing this erroneous deletion. > > > > > > I strongly suggest improving the checks before deletion to avoid this > > > kind of > > > problem in the future. This may be as simple as checking the bind mount > > > points against /proc/mounts before starting the destroy process. > > > > I can see no reason not to add a check against /proc/mounts for any > > entries under $rootfs (if it is a directory). That should definately be > > added. > > I'm attaching the patch I added to my system to try to stop this from > happening > again. The ugly sed to create the grep regex is because rootdev ends up with > two leading slashes instead of one, which wouldn't otherwise match. I suspect > that's simply a bug in the sed two lines before, but I wasn't sure if there > were implications for lvdisplay or btrfs in fixing it, so I left it.
The patch doesn't actually seem to be attached? Note though that lxc-destroy is now a c program. I don't recall whether someone actually stepped up to Stéphane's call for maintainers for older versions - it would be a good thing to have. -serge _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel