getpwnam bug

[Root Boy Jim]

	Anybody ever had a blank line as the first line in your
	password file? It happened to me a few weeks ago and the system
	would not let any user at all log on. Su did not work either.
	In looking at the source I found the following situation:

		getty: calls
		  login: calls
		    getpwnam: calls
		      getpwent: calls
			fgetpwent: which does the following 
	
			p = fgets(line, BUFSIZ, f);
			if (p == NULL)
	  		    return(NULL);
	 
	Since fgets returns NULL if error or end-of-file or if p read 0
	bytes it seems that the search done by fgetpwent terminates
	without searching any further, even though there are further
	valid entries. Is this the way getpwnam always works? (I am
	currently running 4.2BSD/SYS III on a vax 780). I have not seen
	any bug reports filed on this particular problem. Now while
	getting a null entry in the passwd file may be an infrequent
	occurence the only way to recover this is to crash the system
	and come up single-user to repair the passwd file. Thankfully
	my system doesn't prompt for an id coming into single-user mode
	like some systems I've seen. Under that case I think you would
	have no recourse but to restore from a backup.

You are wrong on both accounts. I added a blank line at the head
of my /etc/passwd with no problems. Also, fgets returns a pointer
to a line containing only a newline when reading a blank line.

We run vanilla 4.2BSD on a VAX 750. Perhaps it is the SYS III part
of your system that is messing up, altho I doubt for the reasons
you mention. Fgets is too old a routine to have variations.

	What I think is odd here is that there are other version of
	getpwnam in other utilites that implement the read differently.
	For example:  csh/getpwnam implements the fgets as i =
	read(pwf, line, BUFSIZ).

	Anybody know why csh chose not to use the pw routines?
			
Perhaps it is because of efficiency.

	(Root Boy) Jim Cottrell		<rbj at icst-cmr.arpa>
	..I have read the INSTRUCTIONS...

P.S. Say hi to my dad (same name) if you know him.