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. D. On Sun, Jul 5, 2009 at 10:06 PM, David Pollak<[email protected]> 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 <[email protected]> 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 http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Git some: http://github.com/dpp >
