Re: CDPATH reports to stdout and even non-interactively

[Paul Jarc]

Geoff Kuenning <geoff@cs.hmc.edu> 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