* Charles Blundell (cb@kittenz.org) [021210 16:38]:
> on Tue, Dec 10, 2002 at 04:11:40AM -0800, Alan Post wrote:
> > * Charles Blundell (cb@kittenz.org) [021210 03:33]:
> > > on Tue, Dec 10, 2002 at 02:43:31AM -0800, Alan Post wrote:
> > > > > how do you validate this input?
> > > > 
> > > > In the relevant libc routines (hard), and in the chpass utilities
> > > > (soft).
> > > 
> > > sure, but what's to stop a user not using those routines?
> > 
> > The libc routines used by login(1) can do sanity checking to make sure
> > that the shell is in /etc/shells (and give you /bin/sh otherwise, or
> > something), and so on.
> 
> by which point, the user has locked themselves out.

I don't see how that follows.

> > > oh, i realise that. but how do you implement any policy on passwords?
> > > people will use bad passwords if they can get away with them, even
> > > if this means they use a perl script to generate the hash and pipe
> > > that into some file.
> > > how do you enforce password ageing? if you use the file modification
> > > times, then a simple "touch /etc/userdb/$USER/password_hash" works.
> > 
> > You can enforce aging in login(1).  Bad passwords are harder; you
> > would need login(1) to consult a dictionary of hashed passwords.
> 
> i'm afraid it's quite hard to enforce it in login(1), how do you know
> how old a password is? where does that information come from? how
> is it updated when a user changes their password?
> 
> a dictionary of bad hashed passwords.. would be large.

Yes, this would end up being a rather ugly kludge, though I do think
it would be possible.

> > > one way to control access, but not have an overpowering set-id super-user
> > > access programs, is an intermediary group.
> > > e.g. make chpass setgid auth, and then only allow gid auth access to
> > > the heirachy. unfortunately, you loose access to public data.
> > 
> > If you can alter the username->uid mappings, you can set a user's uid
> > to 0, and you have root.  So I don't see the value in introducing an
> > "auth" user or group.
> 
> consider this heirachy:
> 
> /etc/userdb		root:auth	rwxr-x---
> /etc/userdb/user	root:wheel	rwxr-xr-x
> /etc/userdb/user/uid	root:wheel	rw-r--r--
> ...
> /etc/userdb/user/pwhash	user:wheel	rw-------
> 
> so to change their password, the user must gain both their uid and the
> group auth. group auth has no rights other than read and scan for
> the top level directory.

Neat!  That's a very clever bit.

> > Should I be cc-ing the list then?
> 
> i'm not bothered.