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

[Brett Cannon]

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060627/4f76f071/attachment.html