>> [...optionally keeping passwords in ~/.password or some such...]

>> Any comments from anyone?  I'm imagining getpwent() and friends
>> handling all this transparently,

>> Good idea?  Bad idea?  Problems I don't seem to have thought of?

> I'd stat() it first (or open() and then fstat(), whichever works best
> for NFS attribute caching, etc.) and make sure it`s got no
> permissions set outside of the S_IRWXU mask.  No sense giving users
> too much rope.

I'm of two minds on that.  One is that you can't stop users from
publicizing their password hashes if they choose to, if you let them
get them at all; the other is that you don't want to make it *too* easy
for them to shoot themselves in the foot.  There's also the "UNIX
doesn't stop you from doing stupid things because that would stop you
from doing smart things" - I'm not convinced there's no use for having
a group- or world-readable (or even -writeable!) .password file....

> There are likely some potential problems with locking too, esp. on
> NFS, since at least passwd(1) will need to be able to modify this
> file without allowing any race conditions.

The contents will be small; a single write() should do.  To handle
correctly the case where the new hash is smaller than the old hash
(unlikely, but possible), I'd suggest (a) adding a \n after the
password in the write() call, (b) ftruncate()ing everything past the \n
away, and (c) on read, ignoring everything past the first \n (in case
the read occurs between the write and the ftruncate).

Or, you can look upon it as "if you insist on configuring hashes in
home directories when those homedirs are NFS-remote you deserve
everything you get". :-)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B