[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

Brett Cannon brett at python.org
Tue Jul 11 20:35:23 CEST 2006


On 7/11/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:
> >On 7/10/06, Talin <<mailto:talin at acm.org>talin at acm.org> wrote:
> >>(Although, I've often wished for Python to have a variant of __call__
> >>that could be used to override individual methods, i.e.:
> >>
> >>      __call_method__( self, methodname, *args )
>
> As with so many other things in this discussion, this was already invented
> by the Zope folks just shy of a decade ago.  ;-)  __call_method__ is
> actually a feature of ExtensionClasses, although you can of course
> implement it yourself now atop new-style classes.
>
> For other things that Zope has already done in the area of restricted
> execution R&D, see:
>
>
> http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?view=auto
>
> The surrounding directory has other documents regarding their approach.
>
> I haven't been following this discussion closely, but a lot of the things
> mentioned in this thread seem to have a lot in common with stuff the Zope
> folks have had in production for "untrusted" Python execution for some
> time
> now, working with current versions of Python.  It would be a shame to
> reinvent all the same wheels, especially since their code is nicely
> documented complete with extensive doctests and explanations of the
> approach.


Taking a proxy approach is just being discussed; it has not been decided as
the proper solution.  I have been considering just preventing direct 'file'
access and using open() to act as a delegate for opening files.  That
approach has nothing to do with proxies.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060711/88cfec06/attachment.html 


More information about the Python-Dev mailing list