Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!smoke!sscalsk@nswc-wo.arpa
From: sscalsk@nswc-wo.arpa
Newsgroups: net.unix-wizards
Subject: getpwnam bug
Message-ID: <3299@brl-smoke.ARPA>
Date: Mon, 25-Aug-86 11:34:34 EDT
Article-I.D.: brl-smok.3299
Posted: Mon Aug 25 11:34:34 1986
Date-Received: Tue, 26-Aug-86 05:12:40 EDT
Sender: news@brl-smoke.ARPA
Lines: 31

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.

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?