rick.bullotta at thingworx.com
Tue Mar 25 19:32:40 UTC 2014
We use that capability extensively, Greg. Totally agree that it is easy to comprehend and apply.
From: nashorn-dev <nashorn-dev-bounces at openjdk.java.net> on behalf of Greg Brail <greg at apigee.com>
Sent: Tuesday, March 25, 2014 3:23 PM
To: Nate Kidwell
Cc: nashorn-dev at openjdk.java.net
Subject: Re: nashorn security
Great question -- Rhino had the "class shutter" which was (IMHO) a lot
easier to understand than a proper Java security manager.
On Tue, Mar 25, 2014 at 11:38 AM, Nate Kidwell <nate at slideseed.com> wrote:
> 1) Since people probably are going to be running a variety of
> dynamically-generated code within nashorn, what is done to allow the
> 2) Is something like
> engine.put("java", null);
> engine.put("Java", null);
> engine.put("Packages", null);
> sufficiently secure sandboxing if it is run before a engine.eval(...). Or
> at least if all the bindings are wiped out, would THAT then be sufficient
> 3) Is there any other way to reach outside of the nashorn environment, even
> objects (or java objects that are passed in) that would allow the dynamic
> execution of code on the java side of things.
*greg brail* | *apigee <https://apigee.com/>* | twitter
More information about the nashorn-dev