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

[Brett Cannon]

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


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