Logging rm and kill Requests
Steven G. Isaacson
Sometimes users take it upon themselves to play system
Usually the assistance is welcome. When it's not, you
have to play
This article describes two logging programs that make
easy. One program logs rm requests (see Figure 1 for
entry), the other logs kill requests (see Figure 2).
Logging kill Requests
Why log kill requests?
We needed to log kill requests because of a problem
Standard Engine database. When a user runs a program
the database, two processes are created: (1) the original
and (2) a daemon that handles the database access. (This
is not true
of Informix's OnLine engine.)
We had difficulty with a particular program "locking
so users took it upon themselves to kill their process
when the program
appeared to be stuck. Killing your own process generally
isn't a problem,
but in the case of the Informix daemon it is. If you
kill the Informix
daemon when it's in the middle of a transaction, it's
corrupt the database.
The proper procedure is to kill only the process created
original program. The accompanying daemon process eventually
the signal, at which time it shuts down, does whatever
it needs to do, and then stops.
So our problem was one of education.
It's okay to kill your program, we said, but don't kill
along with it -- even though you can. The daemon will
die on its
own when it's ready. Most of our users got the message
but a few didn't.
We had to find out who kept killing the engine.
We wanted to know: user id, date and time, and information
process being killed.
User and group id are obtained from /usr/bin/id, date
time from /bin/date, and information about the process
to be killed is provided by /bin/ps (you have to get
about the process before it's killed, of course). The
written to a log file and finally the real kill program
called to do the work (i.e., kill the process). Simple.
kill script is in Listing 1.
To install the kill logging script you first rename
/bin/kill program to /bin/rkill. Then move the kill
script to /bin/kill, making sure that everyone has execute
permission for kill and write permission for the log
The "real" kill program (/bin/rkill) is called
from the new kill shell script.
Periodic checks of the log file told us who needed to
about what not to kill.
The same logging technique was developed for rm.
Logging rm Requests
In addition to the information captured in the kill
(user id, date and time, etc.), the rm script records
current working directory. It does this so that files
to the current working directory can be uniquely identified.
For example, if someone types "rm myfile,"
you must know the
current working directory before you can determine if
was removed or /usr/sneed/myfile was removed. Of course,
current working directory is irrelevant if the file
is referred to
by an absolute pathname.
The rm logging script (see Listing 2) is installed in
same way the kill logging script is installed. First
rm program is moved to a new name (/bin/rrm) and the
rm shell script is copied to /bin/rm. Now whenever
a user types "rm filename," the request is
recorded in the
rm log file.
But there are several problems to be aware of.
The first problem with any logging program is the log
file. It keeps
growing. Each request writes multiple lines to the log
file, and with
a frequently used command like rm, this can be a serious
if left unattended, the log file will eventually fill
up your file
A serious problem, but easy to solve.
What you need is a maxtab entry (See "maxtab: Automatic
File Pruning," Sys Admin March/April 1993, vol.
2). Supply the file name and maximum number of lines
and a cronjob
does the rest. We have the kill log file set to 2,000
and the rm log file set to 4,000 lines. This gives us
history of approximately the last 285 kill requests
1,000 rm requests.
The second problem is that there is no secret about
what's going on.
The rm and kill logging scripts are world readable
and anyone can look at them to see how they work.
Soon after one user was "caught" and subsequently
flogged (in a nice way) in email, another user began
using her own
rm script out of her $HOME/bin directory. Her rm
script was the same as the newly installed rm logging
(that is, it calls the real /bin/rrm program), but hers
different in that it didn't bother doing any of the
This problem was quietly addressed by writing a C version
of the scripts.
The C versions work the same, but the logging feature
is hidden because
the contents of the resulting binary file are not as
obvious as those
of a shell script.
The rewrite of the rm-logging program was straightforward
(see Listing 4
for rm.c). The user id, current working directory,
are easily obtainable in a C program, and once that
obtained, it's simply a matter of passing the command-line
on to the real rm program.
The C version of the kill program (see Listing 3 for
was also straightforward, since the difficult part --
about the process about to be killed -- was already
"sukill: Stopping Unruly Processes," Sys Admin
1992, vol. 1, no. 4).
There are other problems, too -- for example, the Network
System (NFS). If you have access to a file system from
any one of
several machines, then you also have access to several
and kill programs. This means that in order to log all
you must install the logging programs on all machines.
Also there may be other kill or rm programs on your
system. We have a program called top that dynamically
the current processes. You can kill processes from within
program -- and bypass /bin/kill logging.
Also, a C program that calls unlink() or kill() directly
is trivial to produce.
In spite of the security shortcomings, the logging programs
They are valuable because they provide information not
available, information that can make your job easier,
that makes playing detective as easy as checking a log
About the Author
Steven G. Isaacson has been programming professionally
since 1985. He works for FourGen Software,
the leading developers of accounting software and
CASE Tools for the UNIX market. He may be reached at
uunet!4gen!stevei or firstname.lastname@example.org.