On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
Yes, you should not change the state once the interpreter is used for execution.
Doesn't matter. I should probably change it to a say "a false value" instead of NULL.
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?
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;
}
Fair enough.
Yeah, being able to read your restrictions seems reasonable to do from an untrusted interpreter.
That has been suggested before. Anyone else like this idea?
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
(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 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.
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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
