Hi all,

I am working on an embedded Ruby application that may support 
user-written Ruby plugins in the future, and I am trying to get a rough 
idea as to what is and isn't possible, as it will affect the design I go 
with. Basically, if you've worked on such a thing before, please share 
your experiences. :)

The ideal in my case is that the app will load in user-written Ruby code 
as a plugin, and the plugin author can interact with the rest of the 
code via a predefined and restricted set of objects and methods, but 
cannot mess with things outside of its environment, and especially not 
start exploring outside that environment in any way. I want to be able 
to completely lock the user out of using certain objects or classes.

Having not done anything like this in Ruby before, I'm trying to get a 
feel as to what might be possible and practical.

For example, many of the criteria in a $SAFE level of 4 seem appropriate 
to me- although what I'm really after is a way to lock things up, call 
some user code, and then revert back to a normal $SAFE level. It looks 
like the only way this could really be done though is to launch the 
plugin in its own (Ruby) thread and handle any synchronisation issues 
arising from it myself. Is this right?

Being able to set up my own access control by intercepting every method 
call made by the plugin would also be useful. I could then, for example, 
have a set of testing criteria that I could use on each method call to 
determine if it should be allowed (for example, class whitelists). I 
wonder if I could set up a series of proxy objects for objects that I'd 
like to wrap, but I wouldn't want a plugin author to use those proxy 
classes to get at the original objects, and mess with them directly. The 
interface could be as thin as two objects- an application object that 
you send messages to, and a plugin base object that the plugin uses to 
receive messages from the application. In this case I'd like the user to 
be able to create their own classes, manipulate strings and arrays (for 
example), but not interact with any of the remaining Ruby code at all, 
and certainly not examine it in any way.

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.

As you can tell, my thoughts on the subject are still somewhat 
disorganised. I'm trying to determine roughly which parts of this 
infrastructure would be easy, difficult, or impossible to implement. I 
would greatly benefit from the thoughts and experiences of people who 
have been down this road before. If you can find the time, please share 
your experiences, and let me know what worked, and what did not.

Thanks in advance, apologies for the long, rambling question. :)

Garth