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