>> Description:
>> If CDPATH is set, whenever bash changes directories to a
>> non-absolute path it reports the new directory to stdout.
>> This is done even if bash is running in non-interactive mode,
>> such as in a script. That breaks scripts that do things like
>> this:
>
> This is the behavior that Posix requires: when CDPATH is used, bash
> outputs the name of the new working directory to stdout. Commands
> and shell functions need to take this into account.
Actually, the Posix standard is ambiguous. Although it (foolishly)
requires reporting to stdout rather than stderr, it does not mention
whether this behavior is required for both interactive and
non-interactive shells.
When the Posix standard is ambiguous or just plain wrong, it's better
to work to change or clarify it than to guess and to slavishly follow
it.
In the current case, it's clearly incorrect to report the new working
directory, which is intended as feedback to humans, to stdout. So the
Posix standard should be changed in the next revision.
> The man page and info doc should list all of the shell variables that
> affect bash's behavior. If that's not the case, please report it.
In other words, "If a sneaky security hole is documented by
implication in the 5000-line man page, there is no need to close the
hole." A better approach is to take an attitude of "To the extent
possible, shell script writers should be able to write secure scripts
without worrying about obscure interactions between their script and
the invoking environment."
> As for IFS, the shell does reset it to " \t\n" at startup (which I
> cribbed from the Korn shell). That's why bash scripts don't reset
> it themselves.
See the above. Dave Korn added that feature because of all the
security holes introduced by IFS, which definitely falls into the
"obscure interactions". We're smarter about that sort of stuff now
than when Steve Bourne wrote the original sh; we should be trying to
minimize that kind of thing rather than maximize it.
> If by (4) you mean that the shell should ignore variables from the
> environment when it starts up in non-interactive mode, there will have
> to be a very good case made to introduce this level of backwards
> incompatibility. That case hasn't been made yet.
I don't mean that the shell should ignore ALL environment variables;
that would break a ton of scripts. Even ignoring PATH would be a Very
Bad Thing, since we've long ago grown used to inheriting PATH.
What I meant was that we should audit the inherited variables, and
make an intelligent and informed decision about each on a case-by-case
basis. See below for suggestions.
> (And the CDPATH issue has come up before. Several times.)
That's a sign that there's a real problem here.
Here's an analysis of all the document environment variables. I'll
only mention variables that might be risky from a security standpoint
BASH_ENV is the cracker's delight. Any setuid program that
invokes a Bash script, even indirectly, is completely
open to attack. I can't see any way to make this
feature safe, although it would certainly help to deny
it if the UID is zero (but there are sensitive
non-root accounts that could still be attacked). It's
worth noting that BASH_ENV has been used in cracks in
the past.
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.
GLOBIGNORE Should be unset in non-interactive mode. I can't come
up with a crack in 10 seconds, but I'm confident that
within 30 minutes I could figure out a way to abuse a
script by controlling its globbing.
HOME Might be abusable, but as with PATH, scripts generally
assume it's untrusted.
IFS Already being reset
IGNOREEOF Already ignored in non-interactive shells (and another
example of where we had to learn the hard way).
MAIL Should be ignored in non-interactive mode (and
probably already is).
OPTERR It's worth noting that bash gets this one right. In
other words, there's precedent for handling other
variables correctly.
PATH Well known, so OK.
POSIXLY_CORRECT
I'm not sure about the security implications of this
one, because I don't know everything it changes.
Superficially, it seems OK, but somebody more
knowledgeable about all its effects should spend some
time thinking about how to crack a script by
manipulating it.
TMPDIR This one is pretty well known. It's abusable, but
removing it would be pretty bad for backwards
compatibility.
--
Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/
The P in "PDF" is a lie.
