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

[Serge Hallyn]

Quoting Dan Fandrich (dan at coneharvesters.com):
> Well, not all of my hard disc, just /lib and /usr/lib, and not all of those
> either because I got suspicious and stopped it before it finished. But
> the damage was severe enough to require an OS reinstall.

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.

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

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

-serge