Brad Fuller wrote:
Thanks that worked -- however it's complaining that it can't find the changes file, but it's in the same directory, and with the same permissions.
On your other note: Can you explain why this is a big security risk? I guess it's at least the known location of where npsqueak was installed by root when the user/root downloaded the package. But, if you're on a system like Windows, couldn't SqueakPlugin.image be easily overwritten by anyone?
Hmm, take a look at the squeak.ini file, the VM is launched in a mode with the default directory is then your My Squeak<username> directory. That is all part of the Squeak secure mode code.
The SqueakPlugin.image is also set so that downloading any file from the web turns on secure mode, restricting access to your file system to the safe directory (see above). "Normal" image don't have that, so if somebody knows/guesses you have the Squeak3.8 image somewhere on your filesystem they might build a squeak project launching page that guesses a location in your filesystem and then executes something nasty. By restricting it to the plugin directory you need to consciously put an image there to enable launching of other images than the squeakland image.
What other issues are there with running the squeak plugin with one's own image? For instance, can I just change the plugin source to download the plugin and image into a user accessible directory to allow the user the ability to change/add/save the image?
You can probably do that, except you are getting into all kinds of interesting security issues as squeak project files can contain arbitrary code.
Or maybe the initial intent of the squeak plugin was temporary -- e.g. dnl "projects" to use per session and not save image state? A browser doesn't really have computing accessibility - so, use the computing power of squeak in a browser window - something you can't get with javascript.
The main intend was to not have the user save the image in an unpredictable state. Actually the automatic update of squeakland does save the image, but before the user has any chance to do anything or before the image has downloaded anything but the updates. And the location for the updates is hardcoded into the image. Which can of course be defeated by DNS pollution hacks, we don't sign the updates (which we probably should do, thinking about it...).
Michael