[ale] diagnosis

[Dow Hurst]

David,
Thinking about your post and the mention of the /var/run/utmp existing for the 
  leak to occur, led me to the man page for utmp to remind myself what wrote 
to it or manipulated it.  Going back to your first post on April 7 I can see 
that you have only the kernel processes, init, bash, and portmap running.  So 
based on this I would start dissecting init and the kernel.  Or, I would 
install a new kernel and init via CD with tools off the CD.  Utmp being a 
database of login entries, and, with several different programs dealing with 
logins operating on utmp, this may be the indicator to help you.  Sorry for 
being vague but I haven't experience with going this far except by reading 
about others who've done it.

Hope this helps you find out what is going on.
Dow



Here is a link to a forensic analysis explanation with an example.
http://www.samag.com/documents/s=9053/sam0403e/0403e.htm



Here is the relevant excerpt from man page for utmp:

The first entries ever created result  from  init(8)  processing  init-
tab(5).   Before  an entry is processed, though, init(8) cleans up utmp
by setting ut_type to  DEAD_PROCESS,  clearing  ut_user,  ut_host,  and
ut_time  with null bytes for each record which ut_type is not DEAD_PRO-
CESS or RUN_LVL and where no process with PID  ut_pid  exists.   If  no
empty  record  with  the  needed ut_id can be found, init creates a new
one.  It sets ut_id from the inittab, ut_pid and ut_time to the current
values, and ut_type to INIT_PROCESS.

getty(8)  locates  the  entry by the pid, changes ut_type to LOGIN_PRO-
CESS, changes ut_time, sets ut_line, and waits  for  connection  to  be
established.   login(8),  after  a user has been authenticated, changes
ut_type to USER_PROCESS, changes ut_time, and sets ut_host and ut_addr.
Depending  on  getty(8) and login(8), records may be located by ut_line
instead of the preferable ut_pid.

When init(8) finds that a process has exited, it locates its utmp entry
by  ut_pid,  sets  ut_type to DEAD_PROCESS, and clears ut_user, ut_host
and ut_time with null bytes.

xterm(1) and other terminal emulators directly  create  a  USER_PROCESS
record  and  generate  the  ut_id  by  using  the  last  two letters of
/dev/ttyp%c or by using p%d for /dev/pts/%d.  If they find a  DEAD_PRO-
CESS  for  this id, they recycle it, otherwise they create a new entry.
If they can, they will mark it as DEAD_PROCESS on  exiting  and  it  is
advised  that they null ut_line, ut_time, ut_user, and ut_host as well.

xdm(8) should not create a utmp record, because there  is  no  assigned
terminal.   Letting  it create one will result in errors, such as ?fin-
ger: cannot stat /dev/machine.dom?.  It  should  create  wtmp  entries,
though, just like ftpd(8) does.

telnetd(8)  sets  up  a  LOGIN_PROCESS  entry  and  leaves  the rest to
login(8) as usual.  After the telnet session ends, telnetd(8) cleans up
utmp in the described way.


-- 
__________________________________________________________
Dow Hurst                  Office: 770-499-3428            *
Systems Support Specialist    Fax: 770-423-6744            *
1000 Chastain Rd. Bldg. 12                                 *
Chemistry Department SC428  Email:   dhurst at kennesaw.edu   *
Kennesaw State University         Dow.Hurst at mindspring.com *
Kennesaw, GA 30144                                         *
************************************************************
This message (including any attachments) contains          *
confidential information intended for a specific individual*
and purpose, and is protected by law.  If you are not the  *
intended recipient, you should delete this message and are *
hereby notified that any disclosure, copying, distribution *
of this message, or the taking of any action based on it,  *
is strictly prohibited.                                    *
************************************************************