eastcoastcoder / gmail.com wrote:

>One concern I have is that I know that eval'd code can modify class
>definitions, and access other objects via ObjectSpace.  Is there anyway
>to eval code so that it can't change Classes and the like?  A true
>Sandbox.
>  
>
Try Ruby uses fork.  I setup the basic environment and then fork new 
interpreters.  I then remove all the constants and methods that could be 
used maliciously.  remove_const and remove_method, that's the secret.  
However, there is some sticky business  involved in trying to close up 
the `ancestors' hole.  I don't yet have an answer that doesn't involve a 
hacked Ruby.

I don't use $SAFE because I didn't want the intrepid student to ever see 
the word `taint' in her's session.  Catch my drift?  (Give it a sec, 
it's drifting down to you right now.)

I don't use threads because I want the student to have all the power to 
screw up her's environment without troubling other students.  In 
addition, I can use FreeBSD's process management to control individual 
sessions.  To prevent fork bombs and endless loops.

But I do use threads inside each session.  One thread for an IRB 
process, one thread for passing data through the FastCGI socket.

_why