Protected execution through tricks with namespace scoping

Tim Peters tim.one at home.com
Sun Jan 14 23:31:40 EST 2001


[posted & mailed]

[rturpin at my-deja.com]
> Two caveats. First, don't ask me why. Second, I'm thinking
> out loud, or more accurately, thinking while I'm typing.
> So there may be gaping errors in the idea below. Almost
> certainly, there are programming errors. At his point, I'm
> working on the concepts, not the syntax.
>
> The goal is to execute plug-in modules in a fashion that
> protects the surrounding program from accidental harm.
> Let's assume the plug-in module is an importable file
> that defines a set of functions. The surrounding program
> wants to supply some named services that are available.
> It seems something like the following would work:
>
> [code building custom dicts and passing them on to an
>  exec to use for locals and globals]
>
> Obviously, either foo or its functions could run forever,
> without returning. Using Python modules that give them
> access to the external environment, they might kill
> processes, screw up files, etc. But is there any way,
> strictly in Python, that either can screw up the
> operation of the surrounding program?

Python has lots of introspective features, so there are holes you're not
likely to think of at first.  For example, if the code you invoke is able to
"import sys", then it can get at sys.modules, and via that replace "the std"
version of any module in the system.  Or it could just
sys.setrecursionlimit(1) and watch things die all over the place.  Etc.

So rather than stumble into these one at a time, read the chapter on
"Restricted Execution" in the Library Reference Manual.  It gives an
overview and then points you to the rexec and Bastion modules, which are
"the std" ways of building a restricted environment in which to run
untrusted code.  Python gives you a lot of help and flexibility here,
enforced at the C level of the interpreter (so it's very hard to subvert).
You're definitely on-target in thinking that namespace-control is a key part
of the game, but there's more to it than *just* that.

and-luckily-it's-already-been-done-for-you-ly y'rs  - tim





More information about the Python-list mailing list