[Python-Dev] doc for new restricted execution design for Python (original) (raw)

Brett Cannon brett at python.org
Tue Jun 27 17:47:28 CEST 2006

On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote:

(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.

Yes, you should not change the state once the interpreter is used for execution.

(2) For the APIs returning an int, it wasn't clear what that int

would be, other than NULL => interpreter is trusted.

Doesn't matter. I should probably change it to a say "a false value" instead of NULL.

I'm not sure that NULL is even always the best answer when the

interpreter is trusted. For example, if I called PyXXXAllowFile, 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.

It's a question of whether you want that interpretation or want to make sure you never call the restriction setters on trusted interpreters. Anyone else have a preference like Jim?

(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?

The PyXXX_Trusted() case is meant as a blanket trusted/untrusted test. If you want more fine-grained, use the other checking functions (e.g., PyXXX_ExtendedCheckValue(), etc.). As I mention in the docs, if you want a "am I allowed to do this, if not I want to do something else", wrap the checking functions in another function and check that function's return value::

int check_for_value(group, type, string) { PyXXX_ExtendedCheckValue(group, type, string, 0); return 1; }

(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.)

Fair enough.

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.

Yeah, being able to read your restrictions seems reasonable to do from an untrusted interpreter.

(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".

That has been suggested before. Anyone else like this idea?

(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.

That's another possibility; having the OS's threading capabilities run individual instances of the interpreter in its own thread instead of having Python manage all of the interpreters itself. I just don't know how feasible that is based on how Python is designed to be embedded and has so much global state.

Thanks for the feedback, Jim!

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060627/4f76f071/attachment.html

More information about the Python-Dev mailing list