Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of feeder.of.the.bears@gmail.com
 designates 209.85.217.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=nYx2JSKFPxPIvt8UD5U0YP+jXsE2XUCLhnj8QNlnXNBYFzk8YBoBcDeJ3BHyM4D8WG
         cliTCaYV44XSUNfOe2yRpacG9TWj7/o7Xhc+ffiYkAshQzPFWPPhkb/Q7Bcgpp/En3Xj
         qGRfShCbNYgl5jTmoXxnkmG5u7xTsxVswIx6k=
MIME-Version: 1.0
In-Reply-To: <c7fc82820907050545v46debeb7i6d3f49be0be86cae@mail.gmail.com>
References: <c7fc82820907050545v46debeb7i6d3f49be0be86cae@mail.gmail.com>
Date: Sun, 5 Jul 2009 13:06:11 -0700
Message-ID: <cdbebedf0907051306r797084aagb883824167ad47ae@mail.gmail.com>
Subject: Re: Scala interpreter action
From: David Pollak <feeder.of.the.bears@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163630f2dfc3c4f9046dfaeb1e

--00163630f2dfc3c4f9046dfaeb1e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <vdichev@apache.org> 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

--00163630f2dfc3c4f9046dfaeb1e--