I manage a technical group which has responsibility
corporate systems. Because the systems include a machine
anonymous access through several different methods,
the group has
to be concerned about who is accessing our systems.
are periodically concerned about the login/logoff session
which takes place. As our workplace is primarily an
SCO shop, we could
resort to using C2 security and the audit facilities
which exist there.
But we don't.
This article was born out of e-mail with another system
who needs to be able to track login and logoff activity
review. The article discusses several different methods
be used. It does not touch on the use of C2 security,
as a later article
will discuss this environmment in detail.
The process of logging onto a UNIX system starts at
All versions of UNIX have a system daemon named init
is responsible for starting system daemons and the getty
getty is responsible for printing a login message and
a user name. Once the user name is collected, getty
login, which then prompts for a password. login validates
password/login name combination, and, if the combination
creates an entry for the login in the /etc/wtmp file,
executes the user's login shell. If the login/password
is incorrect, login asks for a login name again. (For
information on the login process, including password
"How UNIX Password Controls Work," Sys Admin,
1, no. 1, May/June 1992).
An understanding of the options and capabilities of
the who command
is essential to this discussion, largely because of
with the /etc/wtmp file (which will be discussed in
later). In this section, I describe the various options
of the who
command and provide example output.
The who command provides the following options (see
Figure 1 and Figure 2 for more information on these options):
The /etc/wtmp file is a historical record of all of
activity on the system. In fact, a number of events
are included in
this file, and these can be listed using the who command.
Listing 1 shows the structure associated with the /etc/wtmp
file.Login process -- When a getty process
is waiting for a login to occur, a record is written
to indicate the
state of the getty process.
The information is stored in this file in binary form
using the structure shown in Listing 1. As a result, the easiest way to
look at the contents of /etc/wtmp is through the who command.
Logging in and out with the Bourne and Korn Shells
When a user logs in to a UNIX machine with a login shell
or /bin/ksh, the system file /etc/profile is executed
before the file .profile in the user's $HOME directory.
Since /etc/profile is executed for all users, you can
in this file to record the login. For example
echo "LOGIN :`logname`:`tty`:`date`" > /usr/adm/logins
will record the login. The information included is the
login name, the tty where the login took place, and
The command above would generate the following output
in the file
chare:/dev/w2:Sun Jun 13 17:48:16 EST 1993
Unlike the C shell, the Bourne and Korn shells have
built-in mechanism for tracking logouts. However, it's
fool the shell by having it trap the signal which signifies
which is signal 0. The mechanism for accomplishing this
is the shell's
built-in signal handler. The command is trap, and the
trap "command to execute" signal ...
Inserting this command in /etc/profile, as follows,
trap "/usr/local/checkout `logname` `tty`" 0
causes the command checkout to be run a signal
0 is received. At this point you may be wondering why
I don't use
a sub-shell. Signal handlers are not passed to child
so they will not see this handler. A good approach is
the user's login name to a variable such as LOGNAME
terminal being used to a variable named TTY. This increases
the speed at which the logout is executed.
So what is /usr/local/checkout? It could be as simple
line used in /etc/profile for logging in, with a couple
echo "LOGOUT:$LOGNAME:$TTY:`date`" > /usr/adm/logins
Listing 2 shows a sample /etc/profile file with
code added to support the login and checkout scripts.
Listing 3 shows the checkout program, while Figure 3
the output of the login and logout programs in /usr/adm/logins.
Logging in and out with the C shell
For C shell users, the same approach is applicable.
The primary difference
to note is that /etc/profile is not executed, but /etc/cshrc
is. The same syntax shown above for the /etc/profile
here; the one minor difference is that it would be prudent
the '!' after the '>' signs. This disables the no-clobber
feature of the C shell, where it would normally be an
error to append
to a file if the file didn't already exist. An example
echo "LOGIN :`logname`:`tty`:`date`" >! \
You can accomplish this through the use of the .logout
file in the user's $HOME directory. This is somewhat
as it means duplicating a small amount of information
across all of
the users on the system. The amount of information isn't
but it is something to be considered.
Again, the code fragment shown below, which is a variation
/usr/local/checkout program, can be used for the .logout
echo "LOGOUT:$LOGNAME:$TTY:`date`" >! \
Again, note that the '!' is included to prevent
problems with the no-clobber variable in the C shell.
The only reason for collecting information is so that
you can look
at it later. The shell script shown in Listing 4 takes
from /usr/adm/logins and presents it in a meaningful
This shell script is a simple one. It sorts /usr/adm/logins
before processing, using the sort sequence
2. direction (LOGIN/LOGOUT)
I chose this sequence to maintain the connectivity of
logins to logouts
where possible. Sample output of the program in Listing
4 is in Figure 5.
This isn't the most complex reporting program in
the world, but
it illustrates the principle.
While there are many ways of tracking login activity
the methods described here, as well as process accounting,
system auditing, and other services provided by individual
-- there are a few specific things to keep in mind.
In order for the implementation discussed to be of value,
file must be world writeable. This means that anyone
could edit the
file to change the contents. Furthermore, there are
the trap will not be set up and executed when the user
One such case is with the AT&T UNIXPC and 3B1 series
which have a graphical interface. This interface doesn't
a shell, and therefore will not execute the trap set
up in /etc/profile.
In these cases, there will be no corresponding logout
record, as illustrated
in Figure 4.
Some readers may ask why I didn't simply have /etc/profile
execute, run a child shell for the user's interactive
when the user exits with Control D, continue with /etc/profile,
so that the logout information would be recorded. The
is that this would create an additional (and unncessary)
the system. And while such a process would not consume
much in the
way of system resources, it would occupy a process slot
in the process
table, which can be a problem if you are losing 25 or
slots for these activities. It might become necessary
for the system
administrator to make the process table bigger, and
the size of the kernel in RAM, thus decreasing the amount
RAM for user processes.
For more information on system monitoring, see the articles
the Info: u386mon" in Sys Admin, vol. 1, no. 3
1992), and "Getting the Info: sar" in Sys
1, no. 4 (Nov/Dec 1992). For further information on
see your system documentation, and for a specific discussion
login session billing program, see UNIX/World, October
About the Author
Chris Hare is the Technical Services Manager for
Choreo Systems, Inc.
He has worked in the UNIX environment since 1986 and
in 1988 became one of
the first SCO authorized instructors in Canada. He teaches
system administration, and programming classes. His
current focus is on
networking, Perl, and X. Chris can be reached at email@example.com,
firstname.lastname@example.org, which is his home.