In some email I received from der Mouse, sie wrote:
> 
> >> It occurs to me - would it be worthwhile to have a syntax for the
> >> password field in /etc/master.passwd, copied to /etc/passwd by
> >> pwd_mkdb, that says "go look in .password in the user's homedir"?
> > Interesting idea.  If you change such that ~/.password is a copy
> > rather than the repository you might be better off.  Ie. the only
> > change would be for getpwent to check ~/.password if euid != 0 and
> > for passwd to put a copy of the new hash in there if it already
> > exists and is safe etc etc.
> 
> Thinking about it, yes, this is the correct way to go.  You do *not*
> want anyone who manages to write files as joe to be able to thereby
> change joe's password.  (Or maybe you do - perhaps there should be
> *two* magic syntaxes, one which says ".password is the repository" and
> another which says ".password is a copy".)

Allowing password information to exist outside of master.passwd and its
associated database files is a reduction in security no matter which way
you go.

For starters, the ~/.password file is subject to permissions as set by the
user rather than the administrator.

Next, because user home directories are more often NFS'd than /etc, another
avenue is straight away open for obtaining hash'd passwords to start guessing
at.

After that, this "idea" still needs to be have some master control where the
sysadmin. turns it off.  Why turn it off ?  Some people don't like letting
users use chfn, for example, and it strikes me that this administrative
restriction still needs to be available.

Having said the above, I believe (and I've discussed this with a few others
prior, quite some time ago) that creating a "passwd file daemon" which uses
unix domain sockets and the ability to obtain local credentials that way is
the way to go here.  Would anyone like to suggest what sort of functionality
that sort of daemon needs to provide ?

Darren