[pkg-lxc-devel] Bug#839843: /usr/bin/lxc-create: Ran rm -rf on an entire filesystem after failing to create a container
cheetah at fastcat.org
Fri Jan 11 04:30:18 GMT 2019
reassign 839843 lxc-templates 3.0.3-1
On 2019-01-10 18:12, Pierre-Elliott Bécue wrote:
> Matthew, I'm really sorry about the bad experience you've met in 2016.
> guess you don't have the reply to Christian question three years after.
> I'll let the bug open, but I guess it'll never find a solution.
Well, as you surmised I don't have much direct info at this stage, esp.
since this happened on a work machine at a job I have since left.
However looking back at Christian's questions, and comparing that to the
current LXC code and the basics of what I know I was trying to do at the
time, I think I now understand what went wrong.
As you can guess from the directory names, I was working on
instantiating a CentOS container.
Looking at the lxc-centos template in current Buster, I see this code:
echo "Interrupted, so cleaning up"
lxc-destroy -n $name
# maybe was interrupted before copy config
rm -rf $path
trap revert SIGHUP SIGINT SIGTERM
And now the horror show makes a little more sense. I suspect, in trying
to work out how to change where it created the original rootfs from
being under /var to the destination I wanted (a container-named folder
in that /scratch filesystem), I had used --path /scratch. I probably
then realized it was creating the rootfs as /scratch/rootfs not
/scratch/container-name, and hit Ctrl-C. And that triggered the revert
code above, which ran the rm -rf /scratch.
I note that only some of the templates have this pattern -- archlinux,
centos, fedora, fedora-legacy, pld, and void-linux. The lxc-debian
template does not, though it does have a SIGINT handler, that cleans up
something different and which looks guaranteed to be "safe".
So, I guess this bug needs to be reassigned to lxc-templates. I've
tried to do that above, hopefully I didn't fat finger it :)
More information about the Pkg-lxc-devel