[pypy-dev] How to embed PyPy when there's no filesystem?

[tom at twhanson.com]

Armin,
 
A good thought.  Sandboxing may actually be an advantage from a 
security standpoint.  We'll be developing all of the scripts to be 
run, but there's always the chance of hacking. 
 
We can't hard-code the scripts into the binary becuase their purpose is 
to adapt behavior to new configurations.  Because of this the scripts 
will be read from an external source and then executed.  This is what 
makes the the stdin/stdout streaming version attractive. 
 
Thanks,
Tom

On Sat, 25 Apr 2015 09:33:58 +0200, Armin Rigo  wrote:

       Hi Tom,

On 25 April 2015 at 01:32, Maciej Fijalkowski  wrote:
> On Sat, Apr 25, 2015 at 1:13 AM,  wrote:
>> Thanks for the idea. I played with the sandboxed version and it looks like
>> it has potential. 

It's not necessarily the only option. A sandboxed process comes with
a lot of other constrains apart from "no filesystem access". There
are alternatives: you could play in ways similar to how you would
solve this with CPython, namely trying to embed the parts of the
standard library and main program that you need. Just like
sandboxing, we don't have much experience and tools to do that
ourselves, so you still need to come up with all the details (and we
can help, of course). 

Maybe something like: we can tweak pypy_setup_home() to accept NULL as
a path. Then it would not try to automatically set up "sys.path" or
import "site". You're left with what is a broken PyPy, in the sense
that you cannot import anything, but then you can do calls like
pypy_execute_source() to run 5-line scripts --- or even, as a hack, to
declare and install complete modules whose source code you have
previously copied into static strings in your binary. 

A bientôt,

Armin. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150427/02b14ae1/attachment.html>