On Mon, Jun 25, 2012 at 10:18 PM, Chris Cunnington
<
[hidden email]> wrote:
> This is a nice surprise.
>
> My only knowledge with Environments came from Germán's work in the GSoC
> 2010, as demonstrated here:
>
>
http://www.youtube.com/watch?v=n4I7fSVNX2A>
> Your work is quite different. No Environments added as classes in a browser.
> I remember importing code into an Environment being a showstopper. You've
> imported Seaside.
Yes. Germán's work is quite similar to the VisualWorks model, with a
universal hierarchical namespace. I want to avoid Smalltalk ever code
knowing about the image is organized, and just refer to the classes it
needs by name. That'll give us the freedom to load the code into
different environments for different purposes.
> I guess you could have thirty Environments with thirty people doing the
> HelloWorld demo with #renderContentOn:. One image serving thirty people over
> the wire.
Hey, great idea. Environments could be the start of a sandboxing
mechanism, but they wouldn't be secure without other measures—for
example, disallowing access to primitives and dangerous methods like
#nextObject.
> I imagine that the main concern is collisions and not security. But I guess
> if you're importing Smalltalk globals into Environment>>lookup, then you can
> mask out the classes you don't want an Environment to be able to access.
> Say, remove FileDirectory and FileStream, so that those hypothetical Seaside
> users couldn't explore the file system and send the results back to the
> browser.
In practice, I think we'd want an image running inside a sandbox
provided at the operating system level - a solaris zone, freebsd jail
or the like. Being able to compile and run Smalltalk code is just too
powerful a capability to secure within the image.
Colin
Locked
