On Oct 9, 4:32 am, "James Mills" <[EMAIL PROTECTED]> wrote: > On Thu, Oct 9, 2008 at 2:26 PM, Warren DeLano <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
