Date: Sat, 2 Oct 2004 20:53:14 -0400 From: Bill Vermillion <bv@wjv.com> To: freebsd-hackers@freebsd.org Subject: Re: Protecting from the dreaded "rm -fr /" Message-ID: <20041003005314.GA81602@wjv.com> In-Reply-To: <20041003002004.68D8416A4E1@hub.freebsd.org> References: <20041003002004.68D8416A4E1@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 03, 2004 at 00:20 , Men gasped, women fainted, and small children were reduced to tears as freebsd-hackers-request@freebsd.org confessed to all: > > Message: 2 > Date: Sat, 2 Oct 2004 22:43:49 +1000 > From: Peter Jeremy <PeterJeremy@optushome.com.au> > Subject: Re: Protection from the dreaded "rm -fr /" > To: Giorgos Keramidas <keramida@freebsd.org> > Cc: freebsd-hackers@freebsd.org > Message-ID: <20041002124349.GA21569@cirb503493.alcatel.com.au> > Content-Type: text/plain; charset=us-ascii > On Sat, 2004-Oct-02 11:51:43 +0300, Giorgos Keramidas wrote: > >The reason I liked this idea is that root has zillions of other > >ways to destroy an entire system, but not many of them are > >likely to be the result of mistyping a single character as > >shown below: > > # rm -fr / home/someuser/* > I've had a customer write a cronjob that did almost exactly this. > He managed to 'test' it on all the (redundant) production systems > as well as the test model. We were only called in when he found > that there were some unexpected console messages and the systems > wouldn't boot when he pressed the reset button. Luckily it > managed to kill itself before it destroyed all the evidence (since > the culprit initially denied doing anything). > Based on that, I'm definitely in favour of some anti-foot-shooting > measures. > I don't think it should fail quietly: If I ask the computer to do > something (stupid or not), it should either do it or tell me that it > hasn't done it. Failing to do what I ask and not telling me means > that I can't trust the computer - I have to double-check that the > files I wanted to delete have actually gone away. You can always trust the computer to do exactly what you tell it to, even if what you told it to was not what you wanted it to do. If you customer tested the program on non production machines and it failed on the production machine then it was obvious the customer made the mistake of re-creating the crontab line instead of copying it over. The way to keep from shooting yourself in the foot is 1) always check with an 'ls' argument before doing any exterme wildcarding and if you like what you see use your shell editing to change 'ls' to 'rm'. 2) is to let the end user know that certain things are very dangerous and they could destory their system, 3) have automated and verified backups run on the complet system every night. I've been using Unix too long to want to see this behaviour changed, and I'll use the same argument that others do when they advise against aliasing rm to rm -i. If you know that you can't shoot yourself in the foot, you will not treat rm as if it were a loaded automatic pistol and you don't reinforce your double checking. Then one day you go to a machine that doesn't have the safety-net and you make a mistake and it won't be recoverable. If we could arrange to change all the rm's on all the Unix machines in the world at the same - maybe then I'd go for it :-) Bill -- Bill Vermillion - bv @ wjv . com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041003005314.GA81602>