esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Scala interpreter action
Date Mon, 06 Jul 2009 07:03:13 GMT
Should we remove it completely from the source or should we just
deactivate it by default?

I agree that I wouldn't activate it in a producticve setting but it
might be useful while developing.


On Sun, Jul 5, 2009 at 10:06 PM, David
Pollak<> wrote:
> Folks,
> While this feature is interesting, I have to ask that we remove it.
> It's a security hole.  It's problematic in that it makes the messages sent
> to any server with the feature enabled insecure.  Once we get federation (I
> know, I know I keep promising and not delivering federation), then we're
> going to have to care more about trusting servers in the given federation.
> Allowing one of those servers to be compromised by simply having this
> feature turned on, then it makes the federation one of suspicion.
> Or, put another way, Outlook allowed for arbitrary execution of VB code in
> payloads which led to 10 years of virus/worm fighting.  Now, I know this
> feature is not arbitrary code execution of message payloads, there will be
> someone creates a script that has a code injection vulnerability in it.
> So, while this feature feels kind good, I'd much rather see the feature done
> as execution of JavaScript code via Rhino in a high security sandbox (which
> is possible with Rhino.)
> Thanks,
> David
> On Sun, Jul 5, 2009 at 5:45 AM, Vassil Dichev <> wrote:
>> Hello everyone,
>> There is now an action which interprets the text of a message as Scala
>> code and returns back the result. Here's how it works and some things
>> you can do with it.
>> First of all, you need to enable this feature. You will be able to
>> create "scala" actions even if it's disabled, but they won't do
>> anything. To turn it on, use this setting in e.g. default.props (the
>> only one you can rely on in a ):
>>  actions.scala_interpreter.enable=true
>> *Note*: It's sensible to have this feature off by default, as you will
>> gain full control of the JVM in the classloader context of the
>> application. Unless there are security manager restrictions, you might
>> be able to execute OS code, shut down the JVM, modify the database,
>> inspect live objects and possibly change them, etc. This could be both
>> a threat and an advantage.
>> Now it's time to set up our embedded scala interpreter:
>> 1. Create a pool, let's call it e.g. "scalapool"
>> 2. Create an action, which has a filter for the newly created pool. In
>> our example, the filter is "pool:scalapool". The action itself is just
>> "scala". In theory, you could use any filter, but the special symbols
>> necessary for hashtags and users interfere with Scala code. Besides,
>> except for a pool, you don't have much control what gets in your
>> timeline, and I doubt that any unintended message there is valid Scala
>> code.
>> 3. Send some Scala code to scalapool.
>> Let's see what we can do with Scala in ESME:
>> * Calculator
>> Try these:
>> - arithmetic calculations:
>> 3 + 3
>> - string operations:
>> "olleH" reverse
>> -operate on lists, e.g. sum numbers:
>> List(1,2,3,4,5).foldLeft(0)(_+_)
>> As we can see, the result is displayed in a new message, which is a
>> reply to the current one, and is in the same pool. The message source
>> is "scala".
>> Printing to the console won't do what you expect (you won't see it in
>> your reply), so don't use it.
>> * Background execution.
>> Each new message is executed in a separate interpreter. While this has
>> some disadvantages (you lose the bindings for each consecutive
>> execution), there are some advantages to this approach. For instance,
>> you could have several computations execute in parallel, and the
>> previous won't block the next one. Try these messages, one right after
>> the other:
>> {Thread.sleep(10000); "later"}
>> "now"
>> The first message will wait for 10 seconds and then return the string
>> "later". If during those 10 seconds you manage to enter the second
>> message "now", the result will be returned before the result of the
>> first message.
>> This, of course, is an expensive way to schedule reminder messages. If
>> you want it, request a feature in Jira :)
>> * Monitoring
>> -free memory in the JVM:
>> Runtime.getRuntime.freeMemory
>> -total JVM memory:
>> Runtime.getRuntime.totalMemory
>> -current date and timezone on the system:
>> new java.util.Date
>> -get a JVM property, e.g. the JVM version:
>> System.getProperty("java.vm.version")
>> It would be very interesting how this runs in Stax. I tried to use
>> code which works in restricted environments (e.g. I read about
>> problems with classloaders in OSGi). As a whole, I think a sandboxed
>> environment like this is ideal for running ESME with the embedded
>> Scala interpreter, as it offsets the security implications somewhat.
>> As with all powerful features, I would think twice before enabling it
>> in a corporate environment where lots of important messages are
>> stored. On the other hand, I wouldn't hesitate to use it as a training
>> tool in a class where students are able to execute their Scala
>> assignments and the teacher can observe in real time how everyone is
>> doing.
>> So, what do you think? Is this something you find useful? Is there
>> something I missed?
>> Have fun,
>> Vassil
>> P.S. This is another mail in a growing list, which will (hopefully
>> soon) find its way to the wiki documentation or on the blog.
> --
> Lift, the simply functional web framework
> Beginning Scala
> Follow me:
> Git some:

View raw message