[Python-Dev] doc for new restricted execution design for Python

[Jim Jewett]

(1)  Is it impossible for an interpreter to switch between trusted and
untrusted modes?  This is probably a reasonable restriction, but worth
calling out loudly in the docs.

(2)  For the APIs returning an int, it wasn't clear what that int
would be, other than NULL => interpreter is trusted.

I'm not sure that NULL is even always the best answer when the
interpreter is trusted.  For example, if I called PyXXX_AllowFile, I
want to know whether the file is now allowed; I don't really care that
it is allowed because the interpreter is trusted anyhow.

(3)  Should PyXXX_Trusted have a variant that takes group/type/string,
meaning "Am I allowed to do *this*?", rather than having to
special-case the "You can do anything" case?

(4)  For capped resources, there needs to be a way to tell what that
cap is, and how much is left.  (Logically, this provides "how much is
already used", which is already a frequently requested feature for
memory.)

One use of untrusted interpreters is to stop runaway processes.  For
example, it might always be OK to add 4M memory, so long as it has
been at least 10 seconds since the last request.  This requires the
controller to know what the current setting is.

Caps and current usage should also be available (though read-only)
from python; it is quite sensible to spill some cache when getting too
close to your memory limit.

(5)  I think file creation/writing should be capped rather than
binary; it is reasonable to say "You can create a single temp file up
to 4K" or "You can create files, but not more than 20Meg total".

(6)  Given your expectation of one interpreter per web page,
interpreters will have to be very lightweight.  This might be the real
answer to the CPU limiting -- just run each restricted interpreter as
its own "thread" (possibly not an OS-level thread), and let the
scheduler switch it out.

-jJ