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