> is setting it above the HOME/SHELL/TERM/etc settings the right thing
   > to do ?  hopefully, the user knows what they are doing here .. why get
   > in their way ?
   
   Allowing the user to set the SHELL opens all kinds or problematic doors, 
   like in 'login: user SHELL=/sbin/halt'. Making  PATH, HOME, USER and 
   LOGNAME user settable is less risky than SHELL, but still to risky for my 
   taste.  TERM can be argued either way, I choose not to allow it, since 
   there is an established way for setting it, but looking at your example of 
   'login: mry TERM=vt100' convinces me to go the other way :-)

i don't mean that if someone sets SHELL to something else that that
program will be run instead of pw_shell.  simply that these env.
variables be set as the user requests.  LOGNAME and USER are perhaps
problematic -- in a "restricted" environment (not necessarily a
/usr/lib/rsh type one .. i'm thinking of cases where the shell is
a menu program that acts according to $USER.
   
   Disabling the feature on a per account basis is attractive, but until we 
   implement /etc/default/login, I don't see a easy way to do it. Maybe turn 
   the feature off if the SHELL name starts with an 'r' ;-)

well, most other "databases" like this are simply text files in /etc
with a list of usernames in them.  eg, /etc/ftpusers (*) and
/etc/ftpchroot are both used by ftpd to control ftp access.  it could
be as simple as this.


.mrg.

(*) the name here _really_ loses -- /etc/ftpusers is a list of users
who are -not- allowed to use ftp (!).