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

Brett Cannon brett at python.org
Tue Jun 27 18:26:16 CEST 2006

On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote:

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

It can be specified as 1 or whatever. I just planned on a true value.

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

Well, for the filename operation it should be protected by the file object protection anyway, but ignoring this fact, I get your point.

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.

My worry with this is that by providing checking functions that just return true or false that people will rely on those too much and have logic errors in their check and let security holes develop. That is why the checking functions as they stand now are macros that do the error return for you.

If people really need this I can add check functions and rename the current check functions to be more like "require" functions. I just want to hear other people say they will need this that often to warrant the risk of supporting possible security leaks from coding mistakes.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060627/271170d1/attachment.htm

More information about the Python-Dev mailing list