Untrusted code execution

[Ian Kelly]

On Tue, Apr 5, 2016 at 7:43 PM, Steven D'Aprano <steve at 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().