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
