On Tue, Apr 5, 2016 at 7:43 PM, Steven D'Aprano <st...@pearwood.info> wrote: > I think Jon is on the right approach here for restricting evaluation of > evaluation, which is a nicely constrained and small subset of Python. He's > not allowing unrestricted arbitrary code execution: he has a very > restricted (too restricted -- what the hell can you do with just int, str > and len?) whitelist of functions that are allowed, and the significant > restriction that dunder names aren't allowed.
I took that set of builtins to be just for the benefit of example. Presumably a real-world implementer would need to go through a much larger set and evaluate them individually for safety. Most of the builtins apart from compile, eval, exec, exit, input, open, print, quit and the *attr functions are likely safe to include. type might also be a concern since it can be used to assemble arbitrary classes. locals, globals and vars are questionable since it might be possible to trick some non-sandboxed function into calling them. memoryview is also likely best to exclude. I've no doubt I've missed something either. A script that succeeds in finding a way to raise SystemExit would be just as bad as one that calls exit(). -- https://mail.python.org/mailman/listinfo/python-list
