Hi mohtashims,
I agree with everything bakunin, RudiC, and MadeInGermany said.

An alias won't keep users from invoking /bin/rm -f .... A shell function won't keep users from invoking /bin/rm -f ....

But, of course, there is something you can do. Replace /bin/rm with your own version of rm that generates an error message whenever anyone tries to use the -f option. You will get exactly what you want. System maintenance procedures may stop working. System boot procedures may stop working. User shell scripts may stop working. So what; you have made sure that no user is able to avoid an error message when removing a temp file that might not have been created in the first place. Why should they want to do that when they can rewrite their scripts so they will work on your perfected operating system even through their scripts work perfectly on every other POSIX-conforming system in the world.

After modifying rm, are you going to rewrite the manual pages for rm and any utility on your system that might invoke rm with a -f option as well? Or, do you just plan to tell your users that the implementation-supplied man pages are broken and that you have "fixed" the system to work more safely? If third-party software doesn't work on your system because you have fixed rm, are you going to tell those third-party suppliers to "fix" their code to work on your system; or are you going to tell users that they just shouldn't buy from those suppliers because the programmers who wrote their code used an option that you have decided is too dangerous to be allowed to be used on your "improved" system.

And, if a user wants to remove a read-only file from your system, obviously users on your system should learn to use the much safer sequence of commands:

Code:

chmod 644 file
/bin/rm file

instead of the dangerous code:

Code:

rm -f file

After all, typing two or three times as much isn't much more likely to introduce typographic errors is it? And, running two utilities instead of one and accessing a file twice instead of once won't affect system performance, will it?

Or, maybe you want your version of /bin/rm to always behave as if the -i option is in effect. Of course, if you do that, you won't be able to remove any files in a non-interactive script anymore, but so what? Why should anybody be allowed to remove any file without interactively confirming that they really wanted to remove those files? After all, there is no reason why anyone should be allowed to run a cron job that removes temporary files it uses, is there?

And, what about the yes utility? Are you going to remove it to so users can't use:

Code:

yes|rm -i /dir/* > /dev/null

(which they will quickly learn to do since the -f option is no longer available). And, after you remove the yes utility, are you going to fix all of the shells on your system so your users can't use a while loop with echo or printf to simulate the yes utility? Are you going to get rid of the C and C++ compilers so users can't write their own rm utilities and their own yes utilities? And, are you going to remove the chmod, find, rmdir, and unlink utilities from your system so they can't replace:

Code:

rm -rf file...

with the MUCH less efficient:

Code:

find file... ! -type d -exec chmod 600 {} \; -exec unlink {} \;
find file... -type d -depth -exsec chmod 600 {} \; -exec rmdir {} +

? After all, UNIX, Linux, and BSD systems are known for providing lots of ways to do some pretty common things (like remove a file).

If you could fix alias to work the way you want it to, would you remove unalias from all of the shells on your system so users can't get rid of your fix? And, would you fix alias to that an alias for rm can't be redefined?

If you treat your users like foolish children who can't be trusted to use standard operating system features, you will quickly learn that foolish children can turn into rebellious teenagers. And those rebellious teenagers will find ways to get around your restrictions until they are able to move out of your realm of control and work on an unmodified system where they can do their jobs without having to work around your "system improvements". (And don't think that your foolish and rebellious children won't talk to each other and pass around ways to get around your restrictions.)

So, yes, there are lots of things you can try to disable the rm -f option. But, you can't keep users from getting around anything you do. And, you can't keep users from accidentally removing a file (or thousands of files) if they aren't careful typing commands into a shell and when they are responding to prompts issued by every utility they invoke.

You will eventually find out that if you modify your system to become foolproof, a new breed of fool will start using your system.