[lxc-devel] lxc-destroy erased my hard disc

[Dan Fandrich]

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.

>>> Dan