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.
I guess you could have thirty Environments with thirty people doing the HelloWorld demo with #renderContentOn:. One image serving thirty people over the wire.
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.
Cool stuff.
Chris
On Mon, Jun 25, 2012 at 10:18 PM, Chris Cunnington smalltalktelevision@gmail.com 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
squeak-dev@lists.squeakfoundation.org