> 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.
Thanks, I missed that section of the manual. BASH_ENV is already
ignored when euid != ruid.
> 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.)
It would be interesting to know how many scripts use this behavior.
Unfortunately, I can't think of a way to research it.
> CDPATH and GLOBIGNORE could at least be added to the -p handling, I'd
> say.
I'd argue for that at a minimum. It wouldn't fix the situation I
encountered, but it would help.
> 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.
Good point.
Chet Ramey writes:
>> 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.
>
>I'd be interested in seeing that exploited to do something malicious.
Well, I don't really have 30 spare minutes to work something out. But
I might start by arranging for a script that creates and then removes
temp files to fail to remove them due to globbing. Then I might look
for situations where I could cause a denial of service by causing lock
files to not get removed.
--
Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
