Subject: Re: bin/2905: setting environment vars from login
To: Andreas Wrede <firstname.lastname@example.org>
From: matthew green <email@example.com>
Date: 10/31/1996 18:30:55
> 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.
(*) the name here _really_ loses -- /etc/ftpusers is a list of users
who are -not- allowed to use ftp (!).