Disable rm -rf * or rm -rf / in Cent OS

Can some one suggest me the way to disable " rm -rf * " or " rm -rf / " command execution permanently from the server. Any suggestion will be very much helpful .

I assume you're concerned over this so that people can't mess up your system. Actually I don't believe it's possible to do what you want for 2 reasons:
1) rm -rf : this command deletes all files / subdirectories that are located inside your current working directory. If the right permissions are set, a normal user will not be able to delete anything over which he doesn't have write permissions. On the other hand, I (as a normal user) should be allowed to delete the files and the directories that I own.
2) rm -rf /: this command deletes *everything, beginning at the root directory down to the last file / directory in the filesystem tree. Again, if you're not root, you won't be allowed to do it. Now, if you're root and still do that, you are either suicidal or up for a good punch in the face :).

So, rest assured that with the right permissions policy (everything comes down to it) your system should be safe.

If you have any further questions, do not hesitate to let us know :).

What about rm -rf ../* when you're one dir up from root? What about /bin/rm -rf ../* ? What about cd / ; rm -r * ? There are thousands of possible permutations.

What everyone is saying:

1. when your system permissions are correct, and the average user is not logged in as root, things will be fine.

2. You cannot anticipate every command that could delete entire filesystems/ & directory trees. You have to use both permissions, and prevent privileged access.

Thanks for the suggestions guys,

But the question is still half answered . The application which is running on the server has to be accessed or do any code change in it requires root permissions ,so every of the workstation with Cent OS being accessed is given root permissions and most of the programmers are non linux users who are causing this. Atleast it will be good if i can make a message echo "Please verify your command ".

Split the environment. Have the code changes happen on a development server and implement some kind of checkin/transfer to bring the code to the production server.

Hope that could have been in my hand .Its already been developed and now only thing i can do as an admin is to stop the users to stop them from executing the deadly commands

In this case you could think about some workarounds:
You could rename the binary for rm so that only you know it's name, though all places (scripts, cronjobs, etc.) where it is being called will throw an error when they do not find it, for the time of development.
Though you will always have to keep that in mind so when an OS update is to be installed or something similar, you will have to give it it's old name.
Some OSes do have an alias to rm with the -i switch, so that every time it is being issued, you will get a prompt that you have to commit, if you want to delete something.

If the users have root access, you really can't stop them from doing anything.

Requiring everyone to have root access is a bad design. Do you have a bug tracking system? Enter a bug about how giving everyone root access allows everyone to literally destroy the system, even accidentally. Especially if you've already had problems with it happening.

One thing you can do that might help, though, is use the "chattr" utility to set the immutable flag on files you don't want changed or deleted:

chattr +i /some/file/name

In addition to what zaxxon said, you could rename the rm binary and create an alias instead that handles the command and sets custom limitations to it in a script pointing to the renamed binary.

edit: I think you don't even have to rename the binary when you create an alias with the same name. The users will still be able to run the binary of they specify the location though.

You are in a bad situation. You cannot prevent root from being root.

Why does your application need root? Cannot it be encapsulated somehow?

An alias can help, but that will only work interactively, and there are always ways around it.

For the end user level its been encapsulated but for the local development it has been set free to use root.

---------- Post updated at 11:21 PM ---------- Previous update was at 11:12 PM ----------

Guys In one of my screen share sessions with an end user, saw an linux environment where the rm command and usage of any type of special characters have been disabled totally .

@Zaxxon: Is it the same workaround that you mentioned in your comment .
Is it ok to move the binary from the location /etc/sbin to /etc/bin and apply ACL.

---------- Post updated at 11:29 PM ---------- Previous update was at 11:21 PM ----------

achenle : Does the chattr utility you mentioned can be applied to set flag for ownership on a directory and its working on ext3 filesystem. I have been googling it for a time and didnt get the correct answer for these things.Your answer will solve one more important issue for me.

As long as you're OK with them re-enabling it, you can put this in root's ~/.profile or ~/.bashrc or whatever equivalent they use.

alias rm=false
set -f

But this will probably seriously inconvenience them, too.

Moving around essential binaries is not a good idea. If you break something, you may lose the ability to put it back.

Why not just move the rm command and redefine it as a script then you can issue "please verify your command". Of course you will want to be careful, since now rm expects input in the case you're trying to exercise care. Anything that is scripted should run the old version of rm.

Such a fundamental modification would affect every user on the system, including startup scripts, shutdown scripts, and cronjobs, none of which have a controlling terminal with which to prompt and read a response.

I strongly suggest against even considering this suggestion.

Regards,
Alister

It's done all the time and really the whole point behind having both a system level environment file and process level environments.

Replacing core binaries with alternatives that prompt and require a response is "done all the time"?

I'll just walk away from that ludicrous statement now.

Bye.

"All the time"?!!?!

One wonders how on God's good Earth you upgrade or patch a system after you've done that.

Some of the suggestions so far are possibly ok.

I propose a wholly new direction: psychology, not technology

1. The users do not know RH Linux (Centos), or you would not be here with this problem.
2. You can cause them to be a lot more careful with a vague threat.

I do not know how your users get to root, maybe su or sudo. Anyway, as part of root's login message or from the

sudo su - root

add a message:

"Warning: All actions regarding deletion of files using the rm command are being monitored."

Or whatever works in your environment.

Of course, you are monitoring nothing.

But users cannot know how to verify that easily. It is not bulletproof. But you cannot play with core utilities like rm and still have the system behave correctly.

I think you have a management problem. If management will not listen seriously to your problem, and enforce some changes, then you cannot possibly win.

But maybe you can fool enough people to get some stability.