Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.admin
Subject: Re: alternative /etc/passwd formats (was: Corrupted passwd file woes)
Message-ID: <4073@auspex.auspex.com>
Date: 17 Sep 90 18:26:57 GMT
References: <3151@ucsfcca.ucsf.edu> <854@usage.csd.unsw.oz.au>
Organization: Auspex Systems, Santa Clara
Lines: 27

>Well, when I started Uni in '84 we had a couple of PDP11/70s and
>a couple of VAXen running a heavily hacked V7 UNIX. /etc/passwd
>was an autolocking binary file, and libc had been modified to
>know about it... Worked like a charm. Fast. Of course you
>couldn't grep /etc/passwd for stuff,

4.3BSD and later have a similar approach; the difference is that
"/etc/passwd" is *still* a text file, that you can *still* grep, but the
password file that "getpwnam()" and "getpwuid()" get entries from is an
"ndbm" database file.  "vipw" (a misnamed program, it doesn't shove "vi"
down your throat) will rebuild the "dbm" database if you change the
password file with it.

>We currently have about 180 Apollos with 3122 accounts listed.
>The Apollos use a loosely coupled database for account information
>and /etc/passwd is a special file supported by a subsystem which
>generates a standard looking file when you open it for read.

So did they modify "getpwnam()" and "getpwuid()" to talk directly to the
registry, or do they still grovel through said special file?

A similar approach is provided by Sun's NIS and Project Athena's Hesiod,
with a server (an NIS, formerly YP, server in the former case, and an
Internet Domain Name Server such as BIND in the latter case) to which
you send queries.  Both of those make direct queries for "getpwnam()"
and "getpwuid()", rather than fetching every entry from the server and
checking each one.