Safe eval of insecure strings containing Python data structures?
luke.leighton at googlemail.com
Mon Oct 13 14:36:19 CEST 2008
On Oct 9, 4:32 am, "James Mills" <prolo... at shortcircuit.net.au> wrote:
> On Thu, Oct 9, 2008 at 2:26 PM, Warren DeLano <war... at delsci.com> wrote:
> > JSON rocks! Thanks everyone.
> Yes it does :)
> > Ben wrote:
> >>More generally, you should never execute (via eval, exec, or whatever)
> >>*any* instruction from an untrusted path; especially not arbitrary
> >>data from an input stream.
rubbish. this is why a project i was involved with, to do execution
of code from a database instead of a filesystem had to be abandoned,
back in 2001.
there are perfectly good systems for associating security context
with "arbitrary data" (as the security models of SE/Linux, based on
Flask, and the security model of windows nt, based on VAX/VMS
there was a flawed design decision in python 2.2 or python 2.3 which
resulted in an "escape route" - i believe it centered around either
__class__ or __new__ - in the c code, which the developers had not
considered, and would not correct.
this decision resulted in the abandonment of the rexec.py module in
python: you can see for yourself because it raises a runtime exception
when you try to use it, issuing a warning.
it's _perfectly_ possible to define security contexts and boundaries,
and to allow access to functions and modules on a per-security-context
*as defined by the application developer* [not by the developers of
if an individual developer wants to allow "arbitrary code execution
from any data stream", it most certainly is _not_ anyone's place to
dictate to them that they "cannot do this".
instead, there should be a mechanism in place which allows them to
choose which foot they want to lose with the loaded gun they're
More information about the Python-list