> This sounds like a perfect use for the new login.conf mechanism,
> using user classes.  Great!  But, from looking in
> lib/libc/gen/getpwent.c (and from trying it), there seems to be no
> way for libc to fetch the three new-style passwd fields via Hesiod.
> getpwent assumes Hesiod entries are in the old passwd format.

Yeah, you're not the first one to want the new-style passwd fields in
Hesiod (although you might be the second).  If the passwd map were in
an extensible format, it would be more feasible.

I suppose we could implement a hesiod.conf option which says "look up
passwd entries in the 'mpasswd' map instead of the 'passwd' map" and
have the mpasswd map use the new-style passwd format.  That way avoids
doing extra queries.

> So, how can I use Hesiod for passwd lookups, but restrict which
> machines users can log into?  The same problem would exist for NIS
> users.

In the Athena environment, we have basically the same problem, only
without native support for login classes on most of our platforms.
Basically, we want to treat the passwd database as an informational
database about users and deal with access control separately.  Since
we have to extend the login system anyway, we support a file
/etc/athena/access, which just has lines saying "<username> <access
bits>", where <access bits> contains "r" for remote access and "l" for
local access, and <username> can be "*" to match anyone and
"*inpasswd" to match anyone in the local passwd file.

> Besides, doing an ls -l of a directory which contains files owned by
> 5000 different users (think: /export/home) is *much* faster if you
> do the uid->username lookups in Hesiod rather than in the flat file
> that is /etc/passwd.  Try it!

NetBSD doesn't look things up in the flat file which is /etc/passwd.
It uses /etc/pwd.db or (if it can read it) /etc/spwd.db.  I'm a little
surprised that Hesiod is faster, but db might turn out to impose more
overhead than the resolver library and named.