Very Computer

|:What I did not make clear is that the rm command should have
|:the ability to not give a chance to remove certain directories or
|:files at all. For eg. / or vmunix.
|:So if it could read a config file everytime a rm command is issued,
|:and check if the user is trying to delete a sacred file or directory,
|:it could prevent its deletion.

|:Aliasing rm to rm -i is not an option. (Users bypass the alias quite easily)
|
|What a silly notion.  They'll bypass rm if they want.  unlink() isn't privileged.
|
|--tom

Isn't this what Unix file-system permissions are all about?
Make the directory containing the sacred file un-writeable by the
casual user.  For good measure, make the file also un-writeable.

    carl
--
        carl lowenstein         marine physical lab     u.c. san diego

:This was my original note:
:
:>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
:Hi:
:
:I am trying  to find out if anybody out there has modified
: to find out if anybody out there has modified
:the "rm" command to prevent (recursive) removal of important
:files and subdirectories. Any ideas ????

:>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
:
:
:What I did not make clear is that the rm command should have
:the ability to not give a chance to remove certain directories or
:files at all. For eg. / or vmunix.
:So if it could read a config file everytime a rm command is issued,
:and check if the user is trying to delete a sacred file or directory,
:it could prevent its deletion.
:
:Aliasing rm to rm -i is not an option. (Users bypass the alias quite easily)

What a silly notion.  They'll bypass rm if they want.  unlink() isn't privileged.

--tom
--

As the trials of life continue to take their toll, remember that there
is always a future in Computer Maintenance.
                --National Lampoon, "Deteriorada"