[pypy-dev] Sandboxing in Pypy and Crunchy

Andre Roberge andre.roberge at gmail.com
Mon Dec 10 12:49:43 CET 2007


Thanks,  (to all of you)

This clarifies things quite a bit.   Something to look at in 2008,
after the Crunchy 1.0 release.

André

On 12/10/07, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Hi André,
>
> I'm trying to clear up some confusion:
>
> Andre Roberge wrote:
> [snip]
> > On Dec 9, 2007 6:04 PM, Laura Creighton <lac at openend.se> wrote:
> >> the student's code run?  On the student's machine? or on the teacher's
> >> server machine?
> >
> > Right now Crunchy is primarily used in a single user environment.  It
> > would be possible to host it on a server, but it would be very
> > insecure to do so.  Ideally it should be hosted in a secure way on a
> > server in most situations.
> >
> >> The ability to sandbox is a property of the architecture of pypy.
> >> It's not a module that you could port to Cpython.  The person you
> >> want to sandbox has to be running pypy.
> >>
> >
> > Darn :(    I was hoping I could somehow just call a sandboxed
> > interpreter module ....
>
> The sandboxed PyPy Python interpreter needs to be controlled by an
> external Python interpreter to provide the virtual environment for the
> sandbox. This external interpreter can be a completely normal CPython.
> ASCII diagram:
>
> +-----------------------------------------+
> | controlling Python interpreter (CPython)|
> +-----------------------------------------+
>         |                   ^
>         | all communication |
>         v                   |
> +----------------------------------+
> | sandboxed PyPy Python interpreter|
> +----------------------------------+
>
>
> the two boxes are different processes. With a bit of effort, the view of
> the controlling Python on the sandboxed interpreter can be that of a
> simple module that provides a sandboxed way to execute Python code.
> There is also no reason why the outer process cannot control more than
> one sandboxed interpreter. Therefore the answer to your question might
> be yes. Deployment-wise it doesn't behave much like an extension module
> though: You have a bit of pure-Python code for the upper interpreter
> plus a binary with a full Python interpreter.
>
> > Then again, it means that I'll have to try
> > pypy myself, and play with it - something I meant to do ... but did
> > not for lack of time. It also makes it more of a burden on potential
> > users  if they have to install pypy in addition to Crunchy.
>
> Yes, probably. However, you just need this solution only if you want the
> Python code to run on a server, not if the Python code runs on the users
> machine.
>
> Cheers,
>
> Carl Friedrich
>



More information about the Pypy-dev mailing list