calling a function indirectly

[Jim Dennis]

In article <Vg%c8.4179$XT1.116344 at news1.east.cox.net>, Jeff Hinrichs wrote:

>see:
>http://mail.python.org/pipermail/python-list/2001-August/060976.html
>for some info.   Unless you have total control over what is being eval'd you
>are at risk.
>-Jeff

>"Rajarshi Guha" <rxg218 at psu.edu> wrote in message
>news:a50udo$1dou at r02n01.cac.psu.edu...
>> On Wednesday 20 February 2002 01:24 in comp.lang.python Jeff Hinrichs
>wrote:

>>> If you wanted to get away from the dangerous eval, you could put your
>>> functions inside of a class and then,

>> Why is eval dangerous?

 In THIS case it's not a problem.  The string being eval'd is a 
 reference to be bit of code he wrote himself.  However, if it was
 being combined with a string from any untrusted source (esp. 
 user input, or data from a network connection or subprocess, even
 filenames from an os.listdir() or some such, IF that was the case
 then eval could be quite dangerous because it could be executing 
 arbitrary Python code (which could, in turn, execute arbitrary bits
 of system code).

 Regulars on this newsgroup display a knee jerk reaction to eval().
 This could be construed as a healthy wariness in some cases.  One 
 should always ask: 
	where did this data come from? 
	how did I validate it? 
   and especially, 
	what are the risks of using/trusting this data in this way?

 ... but those questions should not be limited merely to strings
 that we might be passing to eval, they must be constantly applied
 throughout our coding if we intend to write robust code which 
 works across security contexts (handles any sort of foreign data)
 and which is capable of enforcing the most basic implicit security
 policy (don't get subverted to executing arbitrary code or tricked
 into removing, or corrupting our data).