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

Phillip J. Eby pje at telecommunity.com
Tue Jul 11 20:59:10 CEST 2006

At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote:

On 7/11/06, Phillip J. Eby <<mailto:pje at telecommunity.com>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><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.: >> >> callmethod( 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. ;-) callmethod 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>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.

My point is more to the study of the requirements for untrusted execution, and what options are open within the existing CPython architecture. Many aspects of the Zope untrusted interpreter do not involve proxies; there are quite a few simple types that Zope's untrusted interpreter allows direct access to. See the section on "Basic objects" in the link above.

More information about the Python-Dev mailing list