<br><br><div><span class="gmail_quote">On 6/27/06, <b class="gmail_sendername">Jim Jewett</b> <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(1) Is it impossible for an interpreter to switch between trusted and<br>untrusted modes? This is probably a reasonable restriction, but worth<br>calling out loudly in the docs.</blockquote><div><br>Yes, you should not change the state once the interpreter is used for execution.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(2) For the APIs returning an int, it wasn't clear what that int<br>would be, other than NULL => interpreter is trusted.
</blockquote><div><br>Doesn't matter. I should probably change it to a say "a false value" instead of NULL. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not sure that NULL is even always the best answer when the<br>interpreter is trusted. For example, if I called PyXXX_AllowFile, I<br>want to know whether the file is now allowed; I don't really care that<br>it is allowed because the interpreter is trusted anyhow.
</blockquote><div><br>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?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(3) Should PyXXX_Trusted have a variant that takes group/type/string,<br>meaning "Am I allowed to do *this*?", rather than having to<br>special-case the "You can do anything" case?</blockquote><div><br>
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::
<br><br> int<br> check_for_value(group, type, string)<br> {<br> PyXXX_ExtendedCheckValue(group, type, string, 0);<br> return 1;<br> }<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(4) For capped resources, there needs to be a way to tell what that<br>cap is, and how much is left. (Logically, this provides "how much is<br>already used", which is already a frequently requested feature for
<br>memory.)</blockquote><div><br>Fair enough.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">One use of untrusted interpreters is to stop runaway processes. For
<br>example, it might always be OK to add 4M memory, so long as it has<br>been at least 10 seconds since the last request. This requires the<br>controller to know what the current setting is.<br><br>Caps and current usage should also be available (though read-only)
<br>from python; it is quite sensible to spill some cache when getting too<br>close to your memory limit.</blockquote><div><br>Yeah, being able to read your restrictions seems reasonable to do from an untrusted interpreter.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(5) I think file creation/writing should be capped rather than<br>binary; it is reasonable to say "You can create a single temp file up
<br>to 4K" or "You can create files, but not more than 20Meg total".</blockquote><div><br>That has been suggested before. Anyone else like this idea?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(6) Given your expectation of one interpreter per web page,<br>interpreters will have to be very lightweight. This might be the real<br>answer to the CPU limiting -- just run each restricted interpreter as<br>its own "thread" (possibly not an OS-level thread), and let the
<br>scheduler switch it out.</blockquote><div><br>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.
<br><br>Thanks for the feedback, Jim!<br><br>-Brett<br></div></div>