UNIX for Advanced & Expert Users

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:

Code:

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.

Code:

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.