Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I think pretty much people here mistakenly 'rm -rf'ed the wrong directory, and hopefully it did not cause a huge damage.. Is there any way to prevent users from doing a similar unix horror story?? Someone mentioned (in the comments section of the previous link) that

... I am pretty sure now every unix course or company using unix sets rm -fr to disable accounts of people trying to run it or stop them from running it ...

Is there any implementation of that in any current Unix or Linux distro? And what is the common practice to prevent that error even from a sysadmin (with root access)?

EDIT: It seems that there was some protection for the root directory (/) in Solaris (since 2005) and GNU (since 2006). Is there anyway to implement the same protection way to some other folders as well??

EDIT: To give it more clarity, I was not asking about general advice about rm usage (and I've updated the title to indicate that more), I want something more like the root folder protection: in order to rm -rf / you have to pass a specific parameter: rm -rf --no-preserve-root /.. Is there similar implementations for customized set of directories? Or can I specify files in addition to / to be protected by the preserve-root option?

share|improve this question
10  
1) Change management 2) Backups. –  mattdm Jan 20 '13 at 17:33
6  
probably the only way would be to replace the rm command with one that doesn't have that feature. –  Keith Jan 20 '13 at 17:40
2  
safe-rm maybe –  sr_ Jan 20 '13 at 18:28
2  
most distros do `alias rm='rm -i' which makes rm ask you if you are sure. besides that: know what you are doing. only become root if necessary. for any user with root privileges security of any kind must be implemented in and by the user. hire somebody if you can't do it yourself.over time any countermeasure becomes equivalaent to the alias line above if you cant wrap your own head around the problem. –  Bananguin Jan 20 '13 at 21:07
1  
@amyassin using rm -rf can be a resume generating event. Check and triple check before executing it –  midnightsteel Jan 22 '13 at 14:21

6 Answers 6

To avoid a mistaken rm -rf, do not type rm -rf.

If you need to delete a directory tree, I recommend the following workflow:

  • If necessary, change to the parent of the directory you want to delete.
  • mv directory-to-delete DELETE
  • Explore DELETE and check that it is indeed what you wanted to delete
  • rm -rf DELETE

Never call rm -rf with an argument other than DELETE. Doing the deletion in several stages gives you an opportunity to verify that you aren't deleting the wrong thing, either because of a typo (as in rm -rf /foo /bar instead of rm -rf /foo/bar) or because of a braino (oops, no, I meant to delete foo.old and keep foo.new).

If your problem is that you can't trust others not to type rm -rf, consider removing their admin privileges. There's a lot more that can go wrong than rm.


Always make backups.

Periodically verify that your backups are working and up-to-date.

Keep everything that can't be easily downloaded from somewhere under version control.


With a basic unix system, if you really want to make some directories undeletable by rm, replace (or better shadow) rm by a custom script that rejects certain arguments. Or by hg rm.

Some unix variants offer more possibilities.

  • On OSX, you can set an access control list on a directory preventing deletion of the files and subdirectories inside it, without preventing the creation of new entries or modification of existing entries: chmod +a 'group:everyone deny delete_child' somedir (this doesn't prevent the deletion of files in subdirectories: if you want that, set the ACL on the subdirectory as well).
  • On Linux, you can set rules in SELinux, AppArmor or other security frameworks that forbid rm to modify certain directories.
share|improve this answer
    
Yeah backing up is the most amazing solution, but I was thinking of something like the --no-preserve-root option, for other important folder.. And that apparently does not exist even as a practice... –  amyassin Jan 22 '13 at 9:41
    
I've edited the question to indicate what I want more... –  amyassin Jan 22 '13 at 20:28
1  
@amyassin I'm afraid there's nothing more (at least not on Linux). rm -rf already means “delete this, yes I'm sure I know what I'm doing”. If you want more, replace rm by a script that refuses to delete certain directories. –  Gilles Jan 22 '13 at 20:32
    
Please edit the last comment to the question as I think it is answering the question well... –  amyassin Jan 22 '13 at 20:38
2  
@amyassin Actually, I take this back. There's nothing more on a traditional Linux, but you can set Apparmor/SELinux/… rules that prevent rm from accessing certain directories. Also, since your question isn't only about Linux, I should have mentioned OSX, which has something a bit like what you want. –  Gilles Jan 22 '13 at 22:17

If you are using rm * and the zsh, you can set the option rmstarwait:

setopt rmstarwait

Now the shell warns when you're using the *:

> zsh -f
> setopt rmstarwait
> touch a b c
> rm *
zsh: sure you want to delete all the files in /home/unixuser [yn]? _

When you reject it (n), nothing happens. Otherwise all files will be deleted.

share|improve this answer
    
+1: nice practical example! –  amyassin Jan 22 '13 at 21:36

One possible choice is to stop using rm -rf and start using rm -ri. The extra i parameter there is to make sure that it asks if you are sure you want to delete the file.

Probably your best bet with it would be to alias rm -ri into something memorable like kill_it_with_fire. This way whenever you feel like removing something, go ahead and kill it with fire.

share|improve this answer
1  
I like the name, but isn't f is the exact opposite of i option?? I tried it and worked though... –  amyassin Jan 22 '13 at 14:24
    
@amyassin Yes it is. For some strange kind of fashion, I thought I only had r in there. Just fixed it. –  NlightNFotis Jan 22 '13 at 16:09
    
I've edited the question to indicate what I want more... –  amyassin Jan 22 '13 at 20:30

EDIT as suggested by comment:

You can change the attribute of to immutable the file or directory and then it cannot be deleted even by root until the attribute is removed.

chattr +i /some/important/file

This also means that the file cannot be written to or changed in anyway, even by root. Another attribute apparently available that I haven't used myself is the append attribute (chattr +a /some/important/file. Then the file can only be opened in append mode, meaning no deletion as well, but you can add to it (say a log file). This means you won't be able to edit it in vim for example, but you can do echo 'this adds a line' >> /some/important/file. Using > instead of >> will fail.

These attributes can be unset using a minus sign, i.e. chattr -i file

Otherwise, if this is not suitable, one thing I practice is to always ls /some/dir first, and then instead of retyping the command, press up arrow CTL-A, then delete the ls and type in my rm -rf if I need it. Not perfect, but by looking at the results of ls, you know before hand if it is what you wanted.

share|improve this answer
    
I've edited the question to indicate what I want more... –  amyassin Jan 22 '13 at 20:29

To protect against an accidental rm -rf * in a directory, create a file called "-i" (you can do this with emacs or some other program) in that directory. The shell will try to interpret -i and will cause it to go into interactive mode.

For example: You have a directory called rmtest with the file named -i inside. If you try to rm everything inside the directory, rm will first get -i passed to it and will go into interactive mode. If you put such a file inside the directories you would like to have some protection on, it might help.

Note that this is ineffective against rm -rf rmtest.

share|improve this answer
    
I've edited the question to indicate what I want more... –  amyassin Jan 22 '13 at 20:28

I like to put the directory name first like this:

$ rm /directoryname -rf
share|improve this answer
5  
this violates POSIX guidelines. –  gelraen Jan 22 '13 at 9:59
    
I've edited the question to indicate what I want more... –  amyassin Jan 22 '13 at 20:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.