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.
[mailto:firstname.lastname@example.org] On Behalf Of Eric Gaudet
Sent: Monday, August 01, 2005 8:58
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.