Safe eval of insecure strings containing Python data structures?

[lkcl]

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
security, show).

 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
basis.

*as defined by the application developer* [not by the developers of
python itself]

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
pointing.

l.