This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 124310

Summary: Openssh breaks on pty/tty name length (PATCH included)
Product: [Fedora] Fedora Reporter: Greg <cheesenapper>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: barryn, moneta.mace, rdeepak
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-07 13:32:08 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Greg 2004-05-25 11:57:58 EDT
Description of problem:

At times, finger reports wildly innaccurate idle times, especially
after logging in remotely from another computer using ssh.  It appears
that random idle information is being generated---notice how the idle
time changes from 162d to 216d after a second finger command:

elisha: ~> uptime
 08:53:14 up 16:05,  3 users,  load average: 0.00, 0.00, 0.00
elisha: ~> finger
Login     Name             Tty      Idle  Login Time   Office    
Office Phone
kriehn    Kriehn           *:0             May 24 16:50
kriehn    Kriehn            pts/1    162d  May 24 16:49 (:0.0)
kriehn    Kriehn            pts/2   15:43  May 24 16:50 (:0.0)
elisha: ~> finger
Login     Name             Tty      Idle  Login Time   Office    
Office Phone
kriehn    Kriehn           *:0             May 24 16:50
kriehn    Kriehn            pts/1    216d  May 24 16:49 (:0.0)
kriehn    Kriehn            pts/2   15:43  May 24 16:50 (:0.0)

The output from the w command...

elisha: ~> w
 08:51:18 up 16:04,  3 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
kriehn   :0       -                Mon16   ?xdm?   2:06   0.07s
-/bin/tcsh -c /
kriehn   pts/2    :0.0             Mon16   15:45m  1.59s  0.17s -csh

Looks like a problem with xdm?  Especially on remote logins?

Version-Release number of selected component (if applicable):

finger-0.17-21
finger-server-0.17-21

How reproducible:

Always

Steps to Reproduce:
1.  Login remotely to a computer via ssh
2.  finger multiple times
3.  Notice wildly inaccurate idle times
  
Actual results:

Random information generated with respect to the idle time

Expected results:

idle time reports accurate information based upon how long they have
been idle

Additional info:
Comment 1 Greg 2004-05-25 13:19:39 EDT
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
Comment 2 R Deepak 2004-06-08 06:56:42 EDT
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@shitei.mindrot.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@mindrot.org 
   ReportedBy: arekm@pld-linux.org 
 
   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! :) 
Comment 3 Greg 2004-06-08 18:41:03 EDT
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
Comment 4 R Deepak 2004-06-08 23:01:37 EDT
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. 
 
 
 
Comment 5 Greg 2004-06-08 23:58:46 EDT
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
Comment 6 R Deepak 2004-06-09 00:11:36 EDT
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. 
Comment 7 Alan Cox 2004-06-15 11:00:20 EDT
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.

Comment 8 Alan Cox 2004-06-15 12:37:45 EDT
Ok I've fixed finger. I have a provisional patch for procps ('w').
Those should get things closer to sanity
Comment 9 Greg 2004-07-02 17:02:20 EDT
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
Comment 10 Greg 2004-07-02 17:06:15 EDT
Looks like a bug report for it has already been filled regarding "who":

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124298
Comment 11 Tomas Mraz 2005-02-07 13:32:08 EST
There is openssh-3.9p1 in FC3. Reopen if it's not fixed.