Bug 124310

After doing some additional poking around, I found that the problem
does not actually occur when there is a login into the system---it
occurs, instead, when a user logs out of the system.  I believe that
wtmp and utmp are not being updated correctly, meaning that the
problem is not with finger, but with how the login/logout records are
generated/updated.  Looks like a much lower-level bug.

Therefore, Steps to Reproduce should be changed:

Steps to Reproduce:
1.  Login to a system
2.  Logout of the system
3.  finger multiple times

This is an sshd problem. Not a finger bug. 
 
There is a solution described here: 
 
http://archive.netbsd.se/?list=openssh-bugs&a=2004-04&mid=188151 
 
-------------- 
 
   Subject: [Bug 855] doesn't properly log logout event in utmp 
entry when pts 
   From: bugzilla-daemon(-at-)mindrot.org 
   Id:<20040428231648.BC0BF27C189.org> 
   Date: Thu, 29 Apr 2004 09:16:48 +1000 (EST) 
   http://bugzilla.mindrot.org/show_bug.cgi?id=855 
 
   Summary: doesn't properly log logout event in utmp entry when pts 
   bigger than 999 
   Product: Portable OpenSSH 
   Version: 3.8p1 
   Platform: All 
   OS/Version: Linux 
   Status: NEW 
   Severity: normal 
   Priority: P2 
   Component: sshd 
   AssignedTo: openssh-bugs 
   ReportedBy: arekm 
 
   The problem is: 
   syslogin_perform_logout() uses char line[8]; so tty name can have 
max 7 
   characters which is not common on recent linux 2.6.5 (and higher) 
systems  
which 
   do not use first free pts number (see 
http://testing.lkml.org/slashdot.php? 
   mid=465538 if you are really interested). 
 
   Due to that there are bad entries in utmp left like: 
   misiek pts/1049 192.168.2.2 Thu Apr 29 01:11 gone - no logout 
   misiek pts/1046 192.168.2.2 Thu Apr 29 01:05 gone - no logout 
   misiek pts/1045 192.168.2.2 Thu Apr 29 01:05 gone - no logout 
   misiek pts/1044 192.168.2.2 Thu Apr 29 01:04 gone - no logout 
 
   Patch to fix issue: 
   diff -urN openssh-3.8p1.org/loginrec.c openssh-3.8p1/loginrec.c 
   --- openssh-3.8p1.org/loginrec.c 2004-04-29 01:06:46.350105456 
+0200 
   +++ openssh-3.8p1/loginrec.c 2004-04-29 01:07:37.357351176 +0200 
   @@ -1354,7 +1354,7 @@ 
   syslogin_perform_logout(struct logininfo *li) 
   { 
   # ifdef HAVE_LOGOUT 
   - char line[8]; 
   + char line[LINFO_LINESIZE]; 
 
   (void)line_stripname(line, li->line, sizeof(line)); 
---------------- 
 
Please fix! :) 

Just built new RPMS for:

openssh-server
openssh-askpass
openssh
openssh-clients
openssh-askpass-gnome 

based upon openssh-3.8.1p1.tar.gz and x11-ssh-askpass-1.2.4.1.tar.gz,
which has the bug fix incorporated in the code (I checked).  After
upgrading with the new rpms, the problem has cleared up.

Thanks for the pointer, and feel free to close this bug!

Greg

I don't think 3.8.1p1 fixes it. 
 
If you look at the code (loginrec.c), you see that in line 1356, 
 
# ifdef HAVE_LOGOUT 
        char line[UT_LINESIZE]; 
 
/tmp/openssh-3.8.1p1$ grep UT_LINESIZE *.h 
defines.h:#ifndef UT_LINESIZE 
defines.h:# define UT_LINESIZE 8 
 
Whereas..  
/tmp/openssh-3.8.1p1]$ grep LINFO_LINESIZE * 
 
loginrec.h:#define LINFO_LINESIZE 64 
loginrec.h:char line[LINFO_LINESIZE];  /* tty/pty name */ 
-------------- 
 
The problem will occur only after 999 "login/logout"s. So are you 
sure 3.8.1p1 fixes it by default? 
 
Anyway, I've build rpm's after making the necessary changes and it 
works fine. Have not tested it with 999 login's yet though. 
 
 
 

Actually 3.8.1p1 does NOT fully correct the problem.  If an ssh
session is broken prematurely, say by closing a terminal window
without "exit"ing or by killing X, then the problem re-surfaces.  It
does not matter whether you are talking about the first login, or the
10th, as the behavior is always the same.

Poking around the code a bit I came to the same conclusion you
did...but too late.

As this bug now seems to relate to broken ssh sessions, should the bug
report be transfered there?

Thanks!
Greg

I don't know. Maybe this is a different problem entirely. 
 
I am not able to reproduce your case unless the allocated pty is 
greater than 999. OTOH, I haven't used remote xdm login's.  
 
Maybe your problem is something else, but sshd also 
corrupts /var/run/utmp when pty > 999. 
 
I'll file this in the openssh section too. 

Ok there are at least two problems here (the 999 one is already a
seperate bug) and the dead bits with FC2.

w is producing garbage for this because an SELinux "fix" broke it.
I've got a patch for that. finger has at least one problem of its own
related to this too. Basically ssh, finger and w all disagree about
how utmp is managed in Linux.

Ok I've fixed finger. I have a provisional patch for procps ('w').
Those should get things closer to sanity

With the installation of the new rpm (finger-0.17.24) reflecting the
patch, the problem has cleared up.  Thanks for all of your work!

I've noticed that "who" is still having problems though.

Thanks!
Greg

Looks like a bug report for it has already been filled regarding "who":

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124298

There is openssh-3.9p1 in FC3. Reopen if it's not fixed.