On Thu, Mar 18, 2010 at 11:25 AM, Ralph Johnson <span dir="ltr"><<a href="mailto:johnson@cs.uiuc.edu">johnson@cs.uiuc.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In my opinion, if you want to grab some code off the internet and run<br>
it in a sandbox, you should spawn a slave image and run it inside that<br>
image. The VM should ensure that any important requests have to go<br>
through the master image.<br>
<br>
In the same way, Croquet really ought to run each island as a separate<br>
image. The UI ought to be able to look into each island to display<br>
it. This would make it easy to prvent cross-island references.<br>
<br>
Similarly, the way to write parallel programs is to spawn an image for<br>
each core. In general, a single image should be a single process. It<br>
should be easy to develop an application that consists of a set of<br>
images.<br>
<font color="#888888"><br>
-Ralph Johnson<br>
<br></font></blockquote><div><br></div><div>There are many ways one could go about sand boxing untrusted code. I think what Michael is after is a more direct, language/framework level support for it. Also, I think we're mixing two orthogonal (but related) matters here, security and concurrency. You don't necessarily need to dump everything into a separate, isolated memory space in order to sand box untrusted code, though that certainly is one way to go about it (and given the current state of things, is probably the most expedient and practical approach). I do agree with your point on parallel programs (one image, one OS process).</div>
<div><br></div><div>- Stephen </div></div><br>