Re: sending code objects around between different interpreters.

Guido.van.Rossum@cwi.nl
Mon, 26 Sep 1994 09:46:47 +0100

> I've been playing around with firing code objects around the local net
> between machines, using compile(), marshal.dumps(), marshal.loads() and
> exec(). The eventual aim of this is a completely extensible management
> tool. However, for fairly obvious reasons, I'd like to be able to
> verify that the code object I'm about to execute is actually from a
> trusted source. Has anyone tried anything like this? Maybe some sort of
> authentication? Or executing the codeobject in a restricted way?

Executing Python code in a restricted way is not yet possible. It
would require a lot of work to find all the places where e.g. using
insanely long strings could crash the interpreter. (I'm not saying
there are loads of holes, just that there are bound to be a few and I
don't necessarily know where the they are...) If you can live with
such crashes, it would be somewhat simpler: all you need to do is
restrict those functions that can modify the file system. Most of
them are in the posix module. I can imagine an API where you have
something like "restricted_exec" and "restricted_eval" which set a
switch that turn on restricted execution. You'd also want to stop the
executed code from stomping on the code that calls it -- probably the
import statement must also be restricted; or perhaps the entire thing
could be executed in a child process... But if forking is OK, a
simpler solution may exist: fork a child and setuid to nobody or some
such...

There's a whole RSA implementation (based on GMU MP) in Demo/rsa --
I'm sure you can use this to build an authentication system in about
half an hour...

If you can live with a string checksum, the md5 module (standard on
most systems!) is all you need...

--Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>