On Dec 18, 2011, at 3:16 AM, Garthy D wrote:
> As some app users might run plugins other app users have written, =
being able to limit the damage they can cause is also important. I'm not =
fussed if certain operations could cause a denial of service (eg. just =
run "while true; end"), as the environment would be such that the =
affected user could just kill the process and disable the plugin- it's =
not a web server. I *would* be fussed though if the plugin was able to =
read and write files to the system directly, or cause lasting damage =
outside of the application itself.

I'm not sure that I would want to rely on any language enforced =
constraints for executing 'hostile' code within the same address space =
as my main application.  I think a better solution is to run the foreign =
code (that sounds nicer) in an external process or even on a completely =
separate system and then use some sort of communication scheme to =
interact with the foreign code. If the communication scheme is well =
defined it also means that the plugin doesn't have to even be in Ruby.

If you want to run it on the same system but in a different process you =
can arrange for the process to be 'locked down' in a sandbox or other =
restricted environment.  The specifics on how to do this are going to be =
very dependent on your production environment but perhaps someone will =
pipe up with some specific suggestions if you tell us about your =
environment.

Gary Wright=