Bert,

> > It's rather straightforward. The only real thing to do is 
> > to return a directory that is assumed to be trusted and one
> > that's assumed to be the root for all untrusted content.
> > Everything else is just setting and returning a bunch of flags.
> 
> The "trusted" directory would be the one containing VM and 
> image, while the untrusted one could be a subdirectory of it, 
> correct?

Not necessarily. It's perfectly valid to have independent locations for each
of the VM, the image, the trusted and the untrusted directory. The key issue
is that the location of neither the VM, nor the image, nor the trusted
directory must be accessible when we limit file access. Also, the trusted
directory must be writable. A possible setup for *nix platforms could be:

	/usr/local/squeak/ [containing VM+image]
	~/.squeak/         [trusted directory]
	~/My Squeak/       [untrusted directory]

Oh, and one more thing. The file access in the security plugin needs to
check for somebody deliberately bypassing the sandbox using ".." or
somesuch. It's perfectly okay to simply fail if you encounter a relative
path - all "official" use of file primitives is based on fully qualified
absolute paths.

Cheers,
  - Andreas