Amit-vax.130 net.unix-wizards utcsrgv!utzoo!decvax!ucbvax!mhtsa!ihnss!eagle!mit-vax!mp Wed Mar 17 18:51:25 1982 uucp and getpwnam() vs. null passwd entries This was sent out to the Arpanet UNIX-WIZARDS list a week and a half ago, but it has seemingly dropped into a black hole, so I'm submitting it this way. Apologies if the original shows up at some time in the distant future. Occasionally we've noticed bogus entries in /etc/passwd, such as ::0:0::: It turns out that these are caused by a bug in getpwent in the C library which caused missing or trailing ':'s or other screwups in the line to cause it to return incorrect passwd structs, including having the trailing newline put into one of the fields. The passwd command, which uses getpwent to read the password file entries and printf's each one back to a new password file, would thus generate bogus entries after each line which had the wrong number of ':'s. There would be many fields containing 0 or 0-length strings, and the printf would be possibly be broken into two lines, both of which had the wrong number of ':'s. Getpwent now takes a premature newline to mean "make all following fields null." Now, passwd is no longer sensitive to missing ':'s, and it actually "fixes" the password file since the printf ensures that there are an appropriate number of ':'s in each line. We haven't quite figured out what to do with extra ':'s in the pw_shell field. These strange entries in /etc/passwd also caused uucp to misbehave, specifically in the expfile() routine. The documentation claims that you can send to ~user/file (~user will get expanded to the user's homedir), or to ~/file (~ will get expanded to /usr/spool/uucppublic, or whatever PUBDIR is). Well, it turns out that uucp's expfile() routine takes everything between the '~' and the '/', calls gninfo() which calls getpwnam(), and uses the resultant pw_dir field. If the lookup fails, THEN it uses the uucppublic directory. Surprise: if your password file has ::0:0::: entries in it, getpwnam("") succeeds, and yields a null directory entry. So, ~/foo expends to /foo, which probably can't be created unless / is writable. Sigh. Mark Plotnick, MIT ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.