Creating a capabilities-based restricted execution system

Aahz aahz at
Sun Jan 4 01:05:13 CET 2004

In article <vveg0bb6is2f60 at>,
John Roth <newsgroups at> wrote:
>"Sean R. Lynch" <seanl at> wrote in message
>news:9Jecnc6TZdy4lGqiXTWc-w at
>> John Roth wrote:
>>> Yes, you're missing something really obvious. Multi-level security
>>> is a real difficult problem if you want to solve it in a believable
>>> (that is, bullet-proof) fashion. The only way I know of solving it
>>> is to provide separate execution environments for the different
>>> privilege domains.  In the current Python structure, that means
>>> different interpreters so that the object structures don't intermix.
>> Hmmm, can you give me an example of a Python application that works
>> this way? Zope seems to be doing fine using RestrictedPython.
>> RestrictedPython is, in fact, an attempt to provide different
>> execution environments within the same memory space, which is the
>> whole point of my exercise. Now, I know that the lack of an example
>> of insecurity is not proof of security, but can you think of a way to
>> escape from RestrictedPython's environment? DoS is still possible,
>> but as I'm not planning on using this for completely untrusted users,
>> I'm not too concerned about that.
>Restricted Python was withdrawn because of a number of holes, of which
>new style classes were the last straw.

RestrictedPython was *not* withdrawn; rexec was withdrawn.  This is a
difficult enough issue to discuss without confusing different modules.  See
Aahz (aahz at           <*>

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.

More information about the Python-list mailing list