[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