Home Original page

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

Jim Jewett jimjjewett at gmail.com
Tue Jun 27 20:07:40 CEST 2006 
On 6/27/06, Brett Cannon <brett at python.org> wrote:
> On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> > On 6/27/06, Brett Cannon <brett at python.org> wrote:

> Shouldn't be as long as you put the call right after variable declarations
> and you don't do an PyObject creation at variable declaration time.

When PEPping this, please add that restriction to the Extension Module
Crippling section.

> > I just want a single call that does my erroring out, instead of two
> > separate calls depending on whether the interpreter is trusted.

> Oh, you won't!  You have the set call before you even start using the
> interpreter to define your restrictions; that has a return value to flag
> that you are trying to set restrictions on a trusted interpreter, and thus
> are trying to do somethign that just won't work.  Then you have the check
> functions that run in *any* interpreter.

This is what I was missing -- the bit about who uses which part of the API.

Is the following correct:


Py_XXXCheck* and Py_XXXExtendedCheck* are called by C extension
modules.  They error out of the current function if the action would
not be allowed.  (In the special case of of a fully trusted function,
the happen to compile themselves out.)

There may be some Py_XXXInfo functions added to find out what the
limits are, particularly for python code.

Py_XXXTrusted() should really be renamed Py_XXXCheckTrusted().
Crippled extension modules should really use Py_XXXCheck*, but
PyXXXCheckTrusted is a quick way to get all-or-nothing.

No other PyXXX functions should ever be (directly) called by any
loadable module, not even by C extension modules; they are called only
by an embedding program.

-jJ
More information about the Python-Dev mailing list