On Jul 27, 2009, at 2:27 AM, Martyn Winn wrote:
This code hasn't changed since 2000, and I think we would have noticed
if there was something fundamentally wrong with it. So before going
off
on a long analysis of shell scripting, it is best to check basics.
What have you changed? You have added an "echo" statement. Why should
that matter? Because the previous line ends in a continuation
marker, so
you have changed what follows that.
Now this seems to be fairly obscure (to me as well, not my code).
http://wiki.tcl.tk/812 has some notes on the "continuation-line
trick".
That article does suggest that it is deprecated, but I'd be loathe to
"fix" something which apparently works for thousands of users.
I guess the question is why did you insert the echo statement? Were
you
trying to fix another problem?
I inserted the echo to see if the variable was defined at that point.
The variable wasn't found to be defined at the script at the point of
the execute command so I made the echo to see if it was before that.
The line continuation is from the CCP4 code, it is not my doing. I
kept it intact to preserve the script as much as possible to see if it
made a difference at the point of the echo, which was meant to be
positionally equivalent to the exec statement.
Anyway, Edward Berry correctly saw that "no such variable" is from
Tcl, shedding some light on the issue: the Tcl environment did not
inherit the variables defined in the parent process.
Having never used exec before because it offends my sensibilities as a
security conscious programmer, I did not know if this were a new
behavior in sh added at the point of my last OS X update to 10.5.7.
I've never seen a variable vanish into thin air unless it was not, as
bash people say, "exported". I know that the variable was exported
because I could see from the ccp4.setup file that it was and should
propagate to child processes. I could attribute such peculiarity only
to some sort of change in the behavior of exec to suppress environment
variables. But from the discussion, I now know the problem was
downstream of exec at the level of Tcl.
You have probably seen by now that I reinstalled ccp4 in the double-
click-no-think way and everything magically started working. So my
best guess is that something went awry during the initial
installation. I'm still puzzled, but have resisted the urge to try to
reproduce the error.
I am also unclear what the connection to injection attacks is?
Here is the vulnerability: CCP4I prompts the user to run as root on
the first go. CCP4I also execs $CCP4I_TCLTK. If I can somehow redefine
$CCP4I_TCLTK in a user's environment perhaps by modifying
their .login, .bashrc, .tcshrc, etc., close to the bottom, then, when
they finally get around to installing CCP4I, I might get control of
their machine. This scenario may sound paranoid, but it is precisely
why Apple decided to change the behavior of sudo to not inherit the
environment of the user. So I'm not the only one with a wild
imagination.
James
