Subject: Re: bin/2905: setting environment vars from login
To: None <current-users@NetBSD.ORG>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
Date: 11/07/1996 11:27:43
Curt Sampson <firstname.lastname@example.org> writes:
> In other words, you're going to make me spend half my life writing
> wrapper programs so that you can add a feature that I don't want.
Why would you sepend half your life writing wrappers? I would have
thought that long before that point was reached you would have
realized it would be better to write just one, slightly more complex,
If such a feature is included, their should also be a way to turn
it off on a user by user basis. That could be by providing
such a generic wrapper, or a config file which login interrogates,
however I think the easiest way to do that would be to allow
arguments shell arguments in the password file. That way, instead
of making the shell "/foo/bar/risky", you could make it
"/usr/bin/env - /foo/bar/risky".
email@example.com (Greg A. Woods) writes:
> If you give me an initial shell (i.e. /bin/sh), I may be able to exploit
> some race conditions to gain interactive shell access. However I won't
> have to muck with any environment variables to get them. If there are
> no race conditions to be exploited, then no amount of fiddling with
> innocuous(*) environment variables will get me any further, unless of
> course you've given me an explicit hole by using some variable in
> /etc/profile that you don't first initialize.
> (*) I.e. variables other than SHELL, PATH, LD_LIBRARY_PATH, or any
> others that a grep of the source tree shows might be risky.
Allowing IFS to be changed is famous for making shell scripts