Hi,
* Nashorn already filters classes - only public classes of non-sensitive
packages (packages listed in package.access security property aka
'sensitive'). Package access check is done from a no-permissions
context. i.e., whatever package that can be accessed from a
no-permissions class are only allowed.
* Nashorn filters Java reflective and jsr292 access - unless script has
RuntimePermission("nashorn.JavaReflection"), the script wont be able to
do reflection.
* The above two require running with SecurityManager enabled. Under no
security manager, the above filtering won't apply.
* You could remove global Java.type function and Packages object (+
com,edu,java,javafx,javax,org,JavaImporter) in global scope and/or
replace those with whatever filtering functions that you implement.
Because, these are the only entry points to Java access from script,
customizing these functions => filtering Java access from scripts.
* There is an undocumented option (right now used only to run test262
tests) "--no-java" of nashorn shell that does the above for you. i.e.,
Nashorn won't initialize Java hooks in global scope.
* JSR223 does not provide any standards based hook to pass a custom
class loader. This may have to be addressed in a (possible) future
update of jsr223.
Hope this helps,
-Sundar
On Tuesday 17 September 2013 09:17 AM, Rod Nim wrote:
Hi Nashorn team!
Are there any recommendations for the best way to restrict the classes that
Nashorn scripts can create to a whitelist? Or is the approach the same as any
JSR223 engine (custom classloader on the ScriptEngineManager constructor)?
I'm also wondering if you have any tips on managing script .js dependencies;
like RequireJS, npm etc?
Thanks in advance!
Rod
