Subject: Re: bin/2905: setting environment vars from login
To: matthew green <mrg@eterna.com.au>
From: Andreas Wrede <andreas@planix.com>
List: netbsd-bugs
Date: 10/30/1996 10:33:01
On Thu, 31 Oct 1996 01:55:34 +1100 matthew green writes
> 
>    
>    This makes me nervous. System V suffers from many security holes made
>    possible by this facility. I'm not personally sure that I would want
>    to see it done unless it was very carefully studied.
> 
> i feel the same way.  however, i can not see any possible security
> problems with this design:  they are only added to the environment
> after fork()/setuid()/etc ... if setting an env. variable in a
> user-land program is a security risk, we have more problems than
> you can think about  :)

That was my analysis when I started this pr.  
 
> as long as the implemtation is not breakable, the design appears to
> be OK.  as i said -- it makes me nervous too -- but as long as the
> implementation is sanity checked i have no problem with it.  it would
> be nice to be able to login somewhere, and say "mrg TERM=vt100" and
> have it DTRT.  perhaps it should be disable-able... to allow
> restricted-type accesses to remain safe ?
> 

> it's not quite a simple problem ...
> 
>    
>    > + 	for (p = logenv; p != NULL; ) {
>    > + 		while ((val = strsep(&p," \t")) != NULL && *val == '\0'
>   );
>    > + 		if (strncasecmp(val,"PATH=",5) != 0)
>    > + 			putenv(val);
>    > + 	}
>    >   	(void)setenv("HOME", pwd->pw_dir, 1);
>    >   	(void)setenv("SHELL", pwd->pw_shell, 1);
> 
> 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 :-)

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' ;-)

-- 
Andreas Wrede              Planix, Inc.
andreas@planix.com         Networking, System Administration, Consulting
http://www.planix.com      Toronto, Ontario, Canada

"The steady state of disks is full."
                               -- Ken Thompson