Home Original page

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

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

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

But what if they succeed?  Do they return -1, 1, the amount allocated, ...

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

You gave an example of a library that was generally useful even in
restricted mode, but had one convenience function that shouldn't
always be permitted.

I imagine a function that is dangerous only because it takes a
filename rather than an open stream; I want to wrap it in some sort of
guard, but I would rather make a single "Can I do this?" query.

Under the current API, I would need separate logic for "The
interpreter is completely trusted" and "The interpreter is not
trusted, but can do _this_".  In practice, I'm betting that many
extension modules will skip at least one of these steps.

-jJ
More information about the Python-Dev mailing list