How to prevent a mistaken rm -rf for specific folders?

Question

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)?

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

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?

@mattdm sure.. but I was curious is there any implementation to prevent such mistakes, as the commenter mentioned... — amyassin, Jan 20 '13 at 17:35
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
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
Let the user do it once and clean up afterwards. Worked like a charm in my case (rm -rf * as root standing at /, no less; caught it after eating most of /bin, had to get the machine to a halfways usable state with the few commands left to be able to shutdown and rebuild. Ah, the memories...). — vonbrand, Jan 21 '13 at 17:13
@vonbrand looks like a good story, similar to that linked above ;) did you tell it any where that I can read?? — amyassin, Jan 22 '13 at 00:09
@user1129682, I don't know if it's true, but I think the distros doing that by default stopped doing it. Having rm aliasing to rm -i is worse because it gets in your way all the time, and one way to override it is with rm -f, so in the end you end forcing users to do more rm -f. Perhaps rm -I (GNU)? — njsg, Jan 22 '13 at 11:49
In the end, this question is pretty much like "How do I prevent accidentally shooting something I don't want to shoot when I fire a gun"... Best way is really to avoid firing a gun in first place, although backups are nice too. — njsg, Jan 22 '13 at 11:50
@njsg no, I was asking more on the direction of 'Is there anything already implemented in the direction of that?' as from the comment in the story linked in the question.. It turned out there is, but only for the root directory! — amyassin, Jan 22 '13 at 11:55
@amyassin: deleting / is different, because it is a special case which you can treat specially. rm -rf is an explicit call to recursively delete something (meaning no special case) without further ado and an implementation that contradics an explicit request won't to anything but leave you with a not fully functional OS, or it will teach people another explicit request that can't be contradicted in which case you can start the same discussion over. It's like becoming root when rm -rf /usr doesn't work. — Bananguin, Jan 22 '13 at 12:59
@amyassin using rm -rf can be a resume generating event. Check and triple check before executing it — midnightsteel, Jan 22 '13 at 14:21
@midnightsteel Resume generating event is a good expression.. It is new to me actually.. thank you :) — amyassin, Jan 22 '13 at 14:27
You can change a file or directory to be immutable (chattr +i), and you can't rm -rf it even as root, but you also can't write to it or change it in anyway until you remove the immutable flag. I've used this in the past for various reasons. — Drake Clarris, Jan 22 '13 at 20:38
Have you looked at chattr? You can make it immutable... Also, there are file access control lists (getfacl setfacl) — JZeolla, Jan 24 '13 at 19:25

Gilles 'SO- stop being evil' · Answer 1 · 2013-01-22T22:16:08.463

16

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.

edited Jan 22 '13 at 22:16

answered Jan 22 '13 at 00:18

Gilles 'SO- stop being evil'

829,060

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 09: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 'SO- stop being evil' 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 'SO- stop being evil' Jan 22 '13 at 22:17
-1 forcing a user write a long poem before anything is deleted might be safe, but is frustrating. Frustrated people make mistakes often. Also, rm -rf / won't do much damage, unless one is logged in as root. – Vorac Apr 05 '13 at 14:03
this is a valuable answer and may have avoid me the pain of rm -rf my home directories – RomainL. Apr 27 '20 at 11:53

score 5 · Answer 2 · answered Jan 22 '13 at 21:29

5

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.

answered Jan 22 '13 at 21:29

qbi

1,419

What is the zsh -f used for ? – Diya Li Dec 23 '19 at 03:40

score 3 · Answer 3 · answered Dec 21 '14 at 03:03

If you understand C programming language, I think it is possible to rewrite the rm source code and make a little patch for kernel. I saw this on one server and it was imposible to delete some important directoryes and when you type 'rm -rf /direcotyr' it send email to sysadmin.

Drake Clarris · Answer 4 · 2013-01-22T20:58:46.997

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.

I've edited the question to indicate what I want more... – amyassin Jan 22 '13 at 20:29 — amyassin, Jan 22 '13 at 20:29

Silverrocker · Answer 5 · 2013-01-23T08:18:58.317

2

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.

edited Jan 23 '13 at 08:18

answered Jan 22 '13 at 14:46

Silverrocker

1,835

I've edited the question to indicate what I want more... – amyassin Jan 22 '13 at 20:28
Awesome trick! The file is easily created with > -i – capitano666 May 14 '18 at 15:15

NlightNFotis · Answer 6 · 2021-07-23T09:25:12.810

1

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.

edited Jul 23 '21 at 09:25

answered Jan 22 '13 at 08:27

NlightNFotis

7,575

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

score -2 · Answer 7 · edited Jan 22 '13 at 03:23

-2

I like to put the directory name first like this:

$ rm /directoryname -rf

edited Jan 22 '13 at 03:23

Michael Mrozek

93,103
40
240
233

answered Jan 22 '13 at 02:08

kieranwild

5

5

this violates POSIX guidelines. – gelraen Jan 22 '13 at 09:59
I've edited the question to indicate what I want more... – amyassin Jan 22 '13 at 20:30

How to prevent a mistaken rm -rf for specific folders?

7 Answers7

Linked