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

[Dan Fandrich]

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.

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

>>> Dan