neild@ux.cs.man.ac.uk (10/14/86)
I would like to hear from anybody who has suggestions on, or knows of implementations of, methods for reducing the consequences of commands like "rm -r *". Particularly when accidently invoked by the super-user in the wrong directory, e.g. "/"! Such methods must be as transparent as possible with regard to the normal usage of "rm". In particular, I am interested in :- 1) A method for protecting files/directories that should not be unlinked/truncated while still allowing their contents to be modified. Making the parent directory non-writable is insufficient as it prevents other files from being created or removed. Further, the super-user should not be able to unlink/truncate protected files without explicitly, and separately, removing said protection first. 2) A method of retaining and reincarnating the pathname and contents of files that have been unlinked/truncated. The retention time of such files should be long enough for a user who has accidently clobbered a file to: realise what they have done, find out how to reincarnate a file and do/request it. Recovery from archives is impractical because they cannot be created often enough without consuming excessive amounts of cpu time and disk space. Please send replies by mail using the addresses below. If requested and if I have time I will post the best suggestions to the net or to those who request them. [Neil, maybe you'd send a summary to mod.os.unix??? -ed] Thanks in advance *=============================================================================* * R Neil Dyer, | * * Dept of Computer Science, | Tel: (+44) 61 273 7121 Ext 5018 * * The University of Manchester, | JANET: neild@uk.ac.man.cs.ux * * Oxford Road, Manchester | UUCP: mcvax!ukc!man.cs.ux!neild * * M13 9PL, | ARPA: neild%uk.ac.man.cs.ux@cs.ucl.ac.uk * * UNITED KINGDOM. | * *=============================================================================*
usenet@cuae2.UUCP (10/26/86)
Looks like the "rm" question is pretty popular. Many people replied
directly to me, the moderator, rather than to the original poster.
Folks, please send your information to the originator, not to me.
I'd much rather have the original poster go through the replies and
summarize back (via me) to mod.os.unix. I'll do it this time....
Actually, this isn't what I really consider to be a summary, because
I've kept the entire text from all the messages I received on this
topic (except the one sent twice from the same person). I've included
everything, because most took a slightly different slant on the problem.
Some are rather ingenious and may have application elsewhere, too.
Have fun. Ron.
----------
From: Paul Scherf <paulsc@orca.TEK.COM>
Organization: Tektronix, Inc., Wilsonville, OR
Your question seems biased towards answers involving kernel
modifications.
There are several people around here who have aliases or scripts
for rm that move the files to a ".deleted" directory instead of
really removing the files. These people also have a "rm
.deleted/*" command in their .logout.
I like this sort of solution, because people who think it is
worth the extra wait for "rm" can wait, and those of us who are
careful don't wait.
I know several people who alias "rm" to "rm -i". These people
get used to typing "y" without thinking. Every one of them has
done an "rm -i *" and sat there and typed "y" for every single
file in the list. Until they got a shell prompt again, they
didn't realize they had deleted several files they wanted to
keep. I don't feel sorry for them.
There is a saying about making things foolproof, and it mentions
something about fools being so ingenious.
Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA
tektronix!orca!paulsc
----------
From: ltuxa!we53!sw013b!dj3b1!killer!cy
Oh, that's an easy one! Make a shell script that does the following and rename
rm to something else, then place this script in /bin/rm and it will be called
everytime rm is called and not the real rm.
1. create a mew directory under root called TRASHCAN.
2. In your script when the "rm -r *" or any other rm is called instead of
erasing anything simply "mv" it to the /TRASHCAN directory. Put a script in
crontab that will empty the /TRASHCAN every week or whenever.
Works great!!! I use it and love it!!!!!
cy
{dj3b1,ihnp4}!killer!cy
----------
From: pegasus!hansen
Organization: AT&T-IS Labs, Lincroft, NJ
Here is the solution I use.
Tony Hansen
ihnp4!pegasus!hansen
< From ulysses!dgk
< Subject: re: rm * considered harmful
<
< I have received several messages about my previous posting titled
< 'rm * considered harmful' and here are a few other solutions.
< Since my orignal proposal is now working on the 3b2, I will send
< a copy of the source code to anyone who requests it.
<
< 1) Make a .trashcan directory under the HOME directory and
< write a local version of rm which links the file there
< before removing it. The problem is that links don't work
< across file systems (although most files you own are
< usually on the filesystem of you HOME directory) and that
< you can have a file with the same name in more than one
< directory. One advantage to this technique is that it
< is simple.
<
< 2) Whenever you create a directory, create a file of mode 000
< with a name that comes early in the dictionary, for example
< #WARNING! Whenever you do an rm with an argument beginning
< with *, you will be prompted with a message because of the
< file mode.
<
< 3) Finally, someone asked whether there was a way ksh could be
< used to prevent rm *. After some thought, I came up with
< the following alias and function which illustrates how you
< can disable file name generation for a specific command.
< Whenever a user types an argument to rm without options which
< has a * in it (except for *.o), the rm is made interactive.
< I have include a copy of the alias and function below for
< anyone who wants to put it in their ENV file.
<
< # Script version of rm which tries to be more intelligent
< # Arguments using * expansion character become interactive if the
< # standard output is a terminal( except *.o).
< # This script requires the 06/29/84 or later release of ksh
<
< alias rm='set -o noglob;_rm' # disable file name generation
< # and then invoke _rm function
< function _rm
< {
< trap 'set +o noglob' 0 # restore file name expansion on exit
< set +o noglob # re-enable file name expansion
< option=
< case $1 in
< -[fri]|-[fri][fri]|-[fri][fri][fri])
< option=$1
< shift
< ;;
< *)
< for i in "$@"
< do case $i in
< *\*.o)
< ;;
< *\**)
< if test -t
< then option=-i
< fi
< ;;
< *)
< esac
< done
< esac
< /bin/rm $option $*
< }
<
<
----------
From: "J.M.Berkley - Computing Services" <ihnp4!watmath!watdcsu!mberkley>
Organization: U. of Waterloo, Ontario
We hemmed and hawed over this at the last company I worked for and
there is no easy solution. For normal naive users you can alias rm to
be "rm -i ", but experienced users - especially those who are
priveleged to have the root passwd - will ALWAYS unalias it or find
ways around the limitations.
Copious backups and limiting the use of root are the best solutions.
Any change to rm will always have loop holes, and the people blessed
with root privelegs will always find a way around it.
These are my own opinions, and I'm sure you've considered the ideas,
but you asked :-)
Mike Berkley
----------
From: seismo!ll-xn!adelie!cdx39!jc
Well, what I usually do is install my own versions of rm,
mv, and cp called Rm, Mv, aand Cp; what they do is rename
any file to be deleted by appending a hyphen to the name.
They do this recursively, so that a series of CP's to 'foo'
will result in foo, foo-, foo---, and so on up to the obvious
upper limit.
Of course, this doesn't work too well for 14-char names.
I also implement a Rs command that removes a hyphen from
each of the names.
It is fairly easy to teach yourself to start each command
with a capital letter; most of us have typed that way for
years.
----------
From: seismo!uwvax!uwslh!jiml (Jim Leinweber)
Organization: Wisconsin State Lab of Hygiene, Madison
Running 4.3 BSD unix on a vax 750 at a site full of neophyte users, we
hacked 'rm' to go into interactive mode when ever more than one file was
specified. That saves our users and occasionally us from some errors, but
is not transparent. 4.3 has 'sticky' directories wherein you must own a
file to remove it, in addition to write permission on the directory.
You could have rm go interactive for even the superuser on sticky directories
only, which would have about the effect you ask. (Obviously rm -fr is not
interactive in this case.)
For unremoving files, either you have to hack the filesystem to order the
free block and i-node lists not to re-use recently free'd stuff till all the old
stuff is gone, or you have to cheat. The former is a bother and a performance
loss. A standard cheat is to have a 'del' command which moves things to more
or less standard places, such as ~/.undelete. They can be restored from there
for a few days, till a cron based find wipes them out.
--
Jim Leinweber jiml@uwslh.uucp jiml%uwslh.uucp@rsch.wisc.edu
{seismo,harvard,topaz,ihnp4,...}!uwvax!uwslh!jiml
State Laboratory of Hygiene @ University of Wisconsin - Madison; (608) 262-8092
----------
From: clyde!bellcore!sw1a7!lhm@mruxc.UUCP
Organization: chi-net, Public Access UN*X, Chicago IL
There was awhile ago a program that came across the net that was
called "rm-unrm". It intercepted the rm command and socked away
a copy of the file in /tmp. The unrm command brought it back. The
program stayed in /tmp until deliberately removed by the superuser
or some cron job.
---
Lee Morehead ...!bellcore!mruxc!sw1a7!lhm|...!ihnp4!chinet!lee
----------
From: ihnp4!aicchi!mdb
Organization: Analysts International Corp., Chicago Branch
We have replaced rm with a shell script. It checks for -r, multiple
files in the list, etc. If it finds them, it tells you what you are
about to do, and gives you a chance to abort it. You can optionally
go thru a list of files (generated by a wildcard name) and specify
what to do for each one.
However, this script is designed to protect the *casual* user. Those
of us who are a little braver (crazier? :-), just play with our PATH to
aviod it.
Mike Blackwell
ihnp4!aicchi!mdb
----------
From: <seismo!hplabs!hpfcdc!hpfclg!hpfcrh!r_ellison>
I have used one method that provides a "second chance" backup for a given
directory. Use
echo > '-i'
to create a file called "-i" in a directory that "rm -r *" might be executed
in. Then, assuming you don't use special characters in filenames, "rm -r *"
will expand to "rm -r -i <other files...>", thus causing "rm" to go into
interactive mode. From interactive mode you can unlink files individually,
or <BREAK>.
This is an easy way to protect, say, "/" from the wrath of "rm -r"; it works
well on users' home directories, too. However, such a file in a subdirectory
will _not_ protect it (only when * expands to have -i first will this
protection work).
It is easy to install and remove, and has saved my tail several times (have you
ever tried to type "rm *.o" and ended up with "rm * .o"?). To remove, either
move the -i file to another name ("mv '-i' i") or remove it in conjunction
with one or more others ("mv a b c -i"), so that the -i appears after a normal
filename. ("rm * -i" will work if you wish to interactively remove all files.)
The -i flag even has precedence over the -f flag, for extra protection.
You could also alias "rm" "rm -i", but this becomes a pain in the neck during
a normal remove. It is useful for beginners, though.
r_ellison
Bob Ellison at HP Fort Collins
--
Ron Heiby usenet@cuae2.ATT.COM Moderator: mod.newprod & mod.os.unix
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109