jim@kovacs.UUCP (05/24/84)
> This is an old article (Mar 84) which I posted and which never made it to the net. > We are running 4.2bsd on a VAX 750. > Recently we've found "null" entries in our passwd file. > They looked like this: > : > :0:: > :0:0:: > : > :0: > Someone here added an entry to the passwd file > and accidently left out the "real life" name field. > The "null" entries followed the bad passwd entry. > Running "/usr/ucb/chfn" caused the null entries to > appear. With "chfn" disabled, we still got them, so > there must be another program which handles missing > fields with the same lack of grace. The problem > went away, of course, when we added the missing field. > Hope this helps someone else with the same symptom. -Jim Keating- R. Abel & Assoc. Hollywood, CA 90038 (213) 462 8100
jaap@haring.UUCP (05/28/84)
> Recently we've found "null" entries in our passwd file. > They looked like this: > : > :0:: > :0:0:: > : > :0: I've seen the same lines and thought is was a problem. (H'm, looks like someone is trying to ``update'' the /etc/passwd file via an illegal way, else he would have done it properly). Actually I was doing this day `cat` to a random file - a random file is always /etc/passwd to me - while trying to find out why this HP2621 didn't work properly with `vi`. The /etc/passwd turned out to be OK, the terminal needed to be repaired. Jaap Akkerhuis Still flabbergasted about the H&P ``firmware''.
johanw@ttdsv.UUCP (Johan Wide'n) (05/31/84)
passwd (the program that sets password) handles lines with
number of fields != 7
ungracefully. Instead of finding out why I have resorted to
regularly running a verification script on /etc/passwd.
(echo passwd ; awk 'BEGIN{FS=":"}{if(NF != 7) print $0 }' \
</etc/passwd ) | mail johanw
{philabs,decvax}!mcvax!enea!ttds!johanw Johan Widenkre@mulga.OZ (Robert Elz) (05/31/84)
From kovacs!jim: > We are running 4.2bsd on a VAX 750. > Recently we've found "null" entries in our passwd file. > They looked like this: > : > :0:: > :0:0:: > : > :0: > Someone here added an entry to the passwd file > and accidently left out the "real life" name field. > The "null" entries followed the bad passwd entry. > Running "/usr/ucb/chfn" caused the null entries to > appear. With "chfn" disabled, we still got them, so > there must be another program which handles missing > fields with the same lack of grace. The problem > went away, of course, when we added the missing field. > Hope this helps someone else with the same symptom. That's caused by a bug in getpwent() that I had hoped had been fixed in 4.2. Oh well. Problem is caused whenever someone (manually, with an editor) miscounts the number of ':' chars in a line in /etc/passwd. From then on, any of the programs that copy passwd and create a new version (passwd, chsh, chfn) will create lots of those annoying colon and zero lines. Its a cancer, the only way to rid your passwd file of it is to completely delete all those lines and correct the line with the missing ':'. If you don't do both of those the problem will simply reappear, and grow continually. (Notice that each of those lines has incorrect numbers of ':' chars so each of them will cause more crap). To the best of my knowledge, this bug exists on all unix versions, its certainly been around ever since getpwent() appeared. I haven't looked at sys III or sys V though, so perhaps its fixed there. The cause of the problem is that pwskip() allows \n to become part of the field returned. None of the programs that write passwd files check for \n in the gecos, or name, or dir fields, they just write it ... Fix is to change the line while (*p && *p != ':') in pwskip() (which is in getpwent.c) to be while (*p && *p != ':' && *p != '\n') Then \n's won't ever make it into fields of passwd structs, and broken passwd file lines won't be cancerous any more. Of course, cancer is often easier to spot than a simple disease ... Robert Elz decvax!mulga!kre ps: this was originally found & fixed here in an early 32v system, by Richard Miller, now hcr!miller or something like that.
kar@ritcv.UUCP (Kenneth A. Reek) (06/03/84)
The "passwd" and "chfn" programs we got with our 4.1 distribution a long time
ago used a very naive locking protocol that failed due to a race condition.
This sometimes resulted in one user's passwd process reading the file at the
same time another user's process was writing it, resulting in missing fields,
truncating the passwd file, and so forth. We changed the passwd program to
use the "link" protocol for file locking and have not had any problems since.
I just took a quick look at the 4.2 passwd code, and the problem appears to be
solved by the use of the exclusive option when opening the lock file.
Ken Reek, Rochester Institute of Technology
{allegra,seismo}!rochester!ritcv!kar