uucp and getpwnam() vs. null passwd entries

[utzoo!decvax!ucbvax!mhtsa!ihnss!eagle!mit-vax!mp]

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