[Python-Dev] Restricted execution: what's the threat model?

[Jim Jewett]

Ka-Ping Yee writes:

>   A.  The interpreter will not crash no matter what Python code
>       it is given to execute.

Why?

We don't want it to crash the embedding app (which might be another
python interpreter), but if the sandboxed interpreter itself crashes,
is that so bad?  The embedding app should just act as though that
interpreter exited, possibly with a status code.

>  B.  Python programs running in different interpreters embedded
>       in the same process cannot communicate with each other.

Why not?  Can't eavesdrop, yes.   Can't force a connection, so that
the other interpreter is free to ignore them.  Maybe even make it
lockable, like sockets -- but it isn't something worth promising.

>   C.  Python programs running in different interpreters embedded
>       in the same process cannot access each other's Python objects.

Note that Brett's assumption of shared extension modules violates this
-- but I'm not sure why he needs to assume that.  (Because of the
init-only-once semantics, I'm not even sure it is a good idea to share
them.)

>   D.  A given piece of Python code cannot access or communicate
>       with certain Python objects in the same interpreter.

Why not?  Is this just a way of allowing lightweight subinterpreters?
Or do you really mean that they can't replace or modify certain
objects, such as the permission-controlling code?

>   E.  A given piece of Python code can access only a limited set
>       of Python objects in the same interpreter.

Does this include objects it creates?  Or are you just saying that it
will behave as if its builtins were segregated, and not see changes
made by another interpreter?

-jJ