Curt Sampson <cjs@portal.ca> 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,
generic wrapper!

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".

woods@kuma.web.net (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
behave unpredictably.

Ian