Subject: pseudo-shadowing of passwords [...]
To: None <tech-security@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-security
Date: 10/07/1998 08:21:08
Håvard writes about passwd.master vs passwd, and the problems it
introduces for things like xlock (basically, lockers usually find they
need to be setuid-root).

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"?  I
don't propose moving _everyone_'s password to ~/.password, if only for
the sake of captive accounts (who often have file upload/download
access) and accounts with nonexistent or shared homedirs.  But it would
be Really Cool if people could read *their own* password hashes without
needing privilege, and besides, it solves a number of "central
repository" problems that have been struggled with in other contexts
and are sometimes best addressed by pushing things into users'
homedirs.  (Mail spool files strike me as an obvious example.)

As I remarked about Greg Woods' desire to be able to mount by
filesystem label rather than /dev entry name, it'd be good to have
available, though it'd be a real problem to have no alternative.

Any comments from anyone?  I'm imagining getpwent() and friends
handling all this transparently, so that if /etc/master.passwd or
/etc/passwd (whichever is being read) says "use homedir", they check
geteuid(), and if it's zero or it matches the uid of the entry, go and
attempt to read out of that file.

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

					der Mouse

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