Path: utzoo!attcan!uunet!cs.utexas.edu!usc!elroy.jpl.nasa.gov!lll-winken!decwrl!shlump.nac.dec.com!asds.enet.dec.com!powers
From: powers@asds.enet.dec.com (Bill Powers)
Newsgroups: comp.os.minix
Subject: observations-possible bug in minix
Keywords: (none)
Message-ID: <12003@shlump.nac.dec.com>
Date: 29 May 90 12:25:21 GMT
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: powers@asds.enet.dec.com (Bill Powers)
Followup-To: comp.os.minix
Organization: Digital Equipment Corporation
Lines: 29


    While working this weekend with Minix, I noticed what appears to
be a bug (rather I personally would, but others might not).  I created
an account that had 8 letters in it.  I then logged into that account
on tty1.  And from tty0, I tried to do a write to that user.  Write
returned a message that the user was not logged on, but they show
up when I do a who.  After doing some investigation, it seems that
that write reads in the utmp?? records and compares the users listed
in there to the one enterd at the command line.  Except the size of the
field for the userid  part of the utmp structure is only 8 characters.
There was no nul terminator on the string so it bled in with the other
records in the file (ie write tried comparing "userid01" with 
"userid01tty1tty1") something like that which made it fail).  To make
a long story short shouldn't the field width for the name field in the
utmp record be 1 more than the longest possible userid.  I also 
noticed that login does a strncpy(utmpnamerecord,username,
sizeof(utmpnamerecord)).  Thus also contributing to the problem by
possibly not terminating the string.  Should not there be a #define in
utmp.h something like #define MAX_USERID_LEN 32.  Then down
in the utmp structure declare the field to be a char array with size
MAX_USERID_LEN+1.  Then in the routines like login, use 
MAX_USER_ID_LEN instead of all the sizeofs?  Does this break some
long standing unixisms?  Did this make any sense to anybody?

Bill Powers
----
Digital Equipment Corp. - Advanced Service Delivery Systems - Stow MA
The opinions expressed above are my own, not my employers.
E-MAIL - powers@asds.enet.dec.com    or   ...!decwrl!asds!powers