Geoff Kuenning <[EMAIL PROTECTED]> wrote: > BASH_ENV is the cracker's delight. Any setuid program that > invokes a Bash script, even indirectly, is completely > open to attack.
Nope. Look at the -p option for set. BASH_ENV can be used to cause scripts to go haywire, but only with your own account. > CDPATH Should be unset in non-interactive mode. Scripts are > unlikely to want to inherit CDPATH; if they want to > use it they can easily set it themselves. Not necessarily. In some cases, it may be that a script relies on the inherited CDPATH as a way for the user to tell it where to operate - that is, a script might treat it just like HOME, PATH, and TMPDIR. In cases like that, the script can't know what value the user wants CDPATH to be set to. (Though it's still true that many other scripts don't treat it that way and may be vulnerable to abuse.) CDPATH and GLOBIGNORE could at least be added to the -p handling, I'd say. The trouble with unsetting an inherited variable in non-interactive shells is that it screws up the situation where an interactive shell invokes a non-interactive shell, which then invokes another interactive shell. The second interactive shell should get the same environment that the first one had, but it won't if the non-interactive one in between makes changes for its own benefit. So a non-interactive shell could simply ignore the inherited value without modifying the environment that it passes on to subprocesses, but that carries surprises of its own. > MAIL Should be ignored in non-interactive mode (and > probably already is). Right. (Likewise for MAILPATH.) Mail checking happens before displaying the primary prompt, which non-interactive shells don't do. paul
