calling a function indirectly

[Jeff Hinrichs]

"Jim Dennis" <jimd at vega.starshine.org> wrote in message
news:a5cnvo$2mdu$1 at news.idiom.com...
> 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).
This is true, but you should always consider that modifications/enhancements
in the future might expose those
"shielded" yet vulnerable sections of code.  With that in mind, you should
always code "on the defensive."
Danger lurks not only where we expect it but where we don't.  So having a
"knee jerk" reaction to eval is proper.  It has a number of uses and can be
quite handy in one shot scripts but any code with a lifetime of more than
one run...."Danger! Will Robinson.  Danger!"

-Jeff