[pypy-dev] PyPy for restricted execution Python

[holger krekel]

[Christopher Armstrong Thu, Aug 19, 2004 at 06:30:59AM -0400]
> On Thu, 19 Aug 2004 11:57:33 +0200, holger krekel <hpk at trillke.net> wrote:
> > I begin to see.  Wouldn't you need quite a lot of access to the
> > gaming application code if you want to give users freedom to script
> > their objects?
> 
> Yeah, there would be a sizeable API. But the access would be very
> carefully moderated and hand-picked. This is really the hard project;

indeed. 

> > I have to admit that if i would go for the "scripting within
> > games" goal i probably wouldn't go for neither of the above.
> > I'd probably think more about kernel-level sandboxes and using
> > unix permissions or posix-acls for file accesses (if any) and a
> > pipe to a VW server to communicate actions and events (with
> > its own security/sanity checks).
> >
> > Hum, maybe there would be a nice application for a (user-mode)
> > linux-kernel and a lean PyPy on top of it with no c-libraries
> > involved whatsoever as this could reduce memory/resource usage
> > to a degree where granting "free accounts" is cheap enough.
> 
> That would be cool, but it seems pretty hard (well, maybe in a few
> more years of computing power advancement ;), and I think it's
> acceptable to only use a limited pool of UMLs that run multiple users'
> code. Here's why.

As PyPy will be faster than C i don't see a speed problem :-)  

Seriously, though, if the code is to interact with a gaming
api and not drive e.g. some graphics hardware i don't see a
big computing power problem with PyPy on top of UserModeLinux 
even if PyPy would be five times slower than CPython. 

> An important distinction to make is that between host and simulation
> security; r-exec is still absolutely necessary even if you have a UML
> for each script. r-exec *can* protect both the host and the
> simulation.

Well, a UML configuration (reused for every script with Copy-On-Write 
or read only FS devices) should provide enough host security, possibly
running on some secure linux capabilities based flavour.  

And, indeed, simulation security has to be taken care off separately. 

Wouldn't it make sense to define a "command protocol" with
integrated simulation security restrictions and provide a 
client side python library for speaking this protocol?  This way the 
user is free to program whatever she pleases but is restricted through 
host security (including CPU/RAM/FS restrictions) and can only produce 
commands which pass simulation security at the server side. 

That being said i wouldn't mind if we can come up with some sensible
easy enough r-exec mechanism within PyPy that would suit your 
Massively Scripted Multiplayer (tm) scenario. Any more ideas anyone? 

cheers, 

    Holger