On Fri, Jul 15, 2011 at 9:31 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > On Fri, Jul 15, 2011 at 9:05 PM, VanL <van.lindb...@gmail.com> wrote: >> On 7/15/2011 1:50 PM, Maciej Fijalkowski wrote: >>> >>> By design, a single process thing is slightly less secure. If you say >>> find a way to corrupt random memory, you can modify the other process, >>> it's still only very slightly though. The sandboxing approach should >>> work quite nicely, the hard part would be to get multiple interpreters >>> running in a single process. It's quite a bit of work, but I would not >>> expect it to be overly hard to do. Requires quite a bit of pypy >>> knowledge though. >>> >> >> Could you describe a little bit more about "quite a bit of work, but... >> [not] overly hard to do"? What would it take, and where would someone get >> started? > > Heh, I was kind of hoping to avoid having to answer that :-) > > You essentially need two things in order to achieve it: > > * have two interpreters in one executable (provided sandboxes don't > have to be separated from each other), one constructed with sandboxing > options the other without. This is something that I would describe as > "run around and make it work", but probably starting with having > either two copies of functions or just two copies of object spaces. > > * change the sandboxing transformation to call some RPython-level API > instead of read/write standard output. Also provide the other end of > this API. As of now the transformation walks around all graphs and > changes external calls into special calls that get rendered as > standard output write and standard input read. > > I know, this is kind of hand-waving what has to be done, I would > probably start with having two interpreters in one executable, > probably by having two object spaces. > > Cheers, > fijal >
And if I may ask, what are you trying to achieve? Cheers, fijal _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
