In article <20021210041006.1D407174D2@arioch.imrryr.org>, Roland Dowdeswell wrote:
> On 1039492294 seconds since the Beginning of the UNIX epoch
> Alan Post wrote:
>>
> 
>>The only disadvantage that I can come up with is that if I am able
>>to impersonate a user, I can set her password without knowing the
>>current one.
> 
> This is actually a pretty major drawback, unfortunately.

The current behavior *requires* either a daemon or setuid program.

Given that you can trojan user init scripts (as mentioned by smb), the
drawback seems to me to be mostly one of timing.  Trojans have to wait
for users to trip over them.

> Other that that, we maintain a hashed DB of the passwd file to speed
> lookups, having it all in separate files would make the lookups
> substantially slower unless you rebuilt the passwd DB.

Ah, pwd_mkdb(8) -- I missed that.  What sorts of applications go heavy
on passwd db lookups?  ls(1) comes to mind as needing lots
of uid->username lookups for pretty output, but there's usually a
limit to how many people are listing files at one time.

> On the bright side, though, you could use the nsswitch (c.f.
> nsswitch.conf(5), nsdispatch(3)) to build an optional framework to
> play with this pretty quickly.

Thanks for the pointer -- I was looking at the code earlier today.  I
figured I'd let people shoot down the idea before I spent time
implementing it.

  Alan