[Python-Dev] doc for new restricted execution design for Python (original) (raw)

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 PyXXXTrusted 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 PyXXXTrusted() case is meant as a blanket trusted/untrusted test. If you want more fine-grained, use the other checking functions (e.g., PyXXXExtendedCheckValue(), 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