Scripting with Groovy

My first real experience with Groovy has started with some mixed results. It’s painfully easy to get started with, but I found the regex support to still smell far too much like the Java regex support, which isn’t nearly as nice as that found in other scripting languages like perl.

The requirement was to add scripting capabilities to HostedQA. This way customers could write more advanced tests that might not be possibly using the basic set of commands we offer for controlling the browser. One such customer requested that a test go to a page and verify all links on the page were valid. A simple script parsing the HTML of the page and visiting all the links solved the problem.

Groovy is great for this kind of loose “glue” code and I’m very happy to offer it to my customers. But there are some concerns:

No easy way to validate the code

No easy way to validate that the supplied code is syntactically correct. I could run the code to check that it is valid, but considering that the script is part of a larger test, mocking out the inputs isn’t really possible.

I also thought about running the code modified with a giant “if (false) { … }” block around it, but because I want to allow some limited imports, that won’t work either - unless I peg the import statements to a pre-selected handful of choices.

Big security hole

I asked about security in the #groovy chat channel on irc.codehaus.org but didn’t get much of a response. Basically, I want to lock down what calls the script can make. I know that I can probably work this out using the JVM policy rules, but I’d prefer to avoid this if possible. Perhaps there are other ways to lock down the objects and methods available for execution?

It doesn’t help that Groovy offers stuff like “rm -rf”.exec()!

I could limit some, but not all of the security concerns by simply locking down import statements. But that still feels “icky”.

No easy way to kill long running processes

Because these scripts are run by untrusted users, they could be very dangerous. A tight loop could peg the CPU for long periods of time. I could of course watch the threads and interrupt them myself, but I really think that this issue and security are both something a scripting container should help with.

Another idea is to run the entire thing in a separate JVM. That would make the overall implementation more complex, but perhaps would give me even greater control.

Conclusion

Scripting in JVMs is a very nice tool. And if I can figure out these issues, I think that this type of glue code could really enhance the HostedQA offering. But I can’t really go live with it until I have an answer for these problems. Does anyone have any suggestions?