Hello Eric, Mark, and Alexey,


> I am willing to contribute a patch for each of these features if people are interested.


I think its safe to say people are interested.  If you have implemented this with tests we would love to see it.  The same goes for Mark’s custom security policy.





From: beanshell-users-admin@lists.sourceforge.net [mailto:beanshell-users-admin@lists.sourceforge.net] On Behalf Of Eric Gaudet
Sent: Monday, August 01, 2005 8:58 AM
To: beanshell-users@lists.sourceforge.net
Subject: [Beanshell-users] Sandboxed BeanShell?


Hi all,


I'm new to BeanShell and I'm evaluating the possibility to include it in our product.


So far, I'm very impressed with the features. It's a very powerfull tool for developers. However, I fear it could be a very insecure scripting tool in hands of customers.


Let me explain: I'm looking for a macro evaluator with a well-defined, limited number of features, to be embedded in our application. "Customers" actually refers to administrators in customer sites preparing scripts for user actions. Scripts cannot be uploaded by just anybody. But people make mistakes, even developers, and killing a production server because of a bug in a script is not an option. Also, part of our API is not public and should only be used internally.


Some of my concerns are similar to the one expressed in the "too powerfull" thread. I'm very unhappy with the answers I read: not allowing scripts with infinite loops is a *very* legitimate request, and the answers were either silly or sounded like people didn't care.

Most embedded scripting engines address the problem by limiting the number of "steps" allowed within one run. The definition of "steps" doesn't have to be strict and can assume that external java classes don't create infinite loops themselves. It's just a matter of counting the number of AST objects evaluated and throw an exception if the maximum defined in the interpreter is reached.


Another concern is the unrestricted access to classes by scripts. I'm talking about the ability to import any class at any time. I know that there are security settings, but what I really want is to lock the classpath accessible from inside a script. Basically, disabling the import command would give more control over what's runnable by a script: my macro evaluator would never be allowed to create a swing window and wait forever for a button to be pressed on a remote server I rarely log in.


I am willing to contribute a patch for each of these features if people are interested.