AccessControlException (FilePermission) on startup prevents running any script whatsoever

[hakanai]

This is either an old permissions-related issue resurfacing, or another issue which has always existed on Mac OS X and I've only just started hitting it now because we're trying to get all our stuff to work on other platforms.

The code we're running is just from our tests:

ScriptEngine engine = new ScriptEngineManager().getEngineByExtension("rb");
ScriptContext context = engine.getContext();
context.setAttribute(ScriptEngine.ARGV, new String[] { "a", "b" }, ScriptContext.ENGINE_SCOPE);
Object result = engine.eval("ARGV.shift + ARGV.shift", context);

We're using a policy file which permits access to anything in the current directory.
For context, jruby-complete.jar is in this directory too.

grant {
    permission java.io.FilePermission "${user.dir}/-", "read, execute";
};

On running, the process bombs with:

javax.script.ScriptException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/Volumes/Big%20Data/Projects/acme/trunk/product/dependencies/jruby/jruby-complete.jar" "read")
    at org.jruby.embed.jsr223.JRubyEngine.wrapException(JRubyEngine.java:104)
    at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:93)
    at com.acme.integration.vendor.jruby.TestCommandLine.testCommandLineArrayViaScriptEngine(TestCommandLine.java:27)
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/Volumes/Big%20Data/Projects/acme/trunk/product/dependencies/jruby/jruby-complete.jar" "read")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
    at java.security.AccessController.checkPermission(AccessController.java:559)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
    at java.util.zip.ZipFile.<init>(ZipFile.java:206)
    at java.util.zip.ZipFile.<init>(ZipFile.java:145)
    at java.util.jar.JarFile.<init>(JarFile.java:153)
    at java.util.jar.JarFile.<init>(JarFile.java:90)
    at org.jruby.runtime.load.LoadService.getJarFile(LoadService.java:1371)
    at org.jruby.runtime.load.LoadService.tryResourceFromJarURLWithLoadPath(LoadService.java:1347)
    at org.jruby.runtime.load.LoadService.tryResourceFromLoadPathOrURL(LoadService.java:1313)
    at org.jruby.runtime.load.LoadService.findLibraryWithoutCWD(LoadService.java:1057)
    at org.jruby.runtime.load.LoadService$NormalSearcher.trySearch(LoadService.java:755)
    at org.jruby.runtime.load.LoadService.findFileForLoad(LoadService.java:411)
    at org.jruby.runtime.load.LoadService.smartLoadInternal(LoadService.java:560)
    at org.jruby.runtime.load.LoadService.requireCommon(LoadService.java:457)
    at org.jruby.runtime.load.LoadService.require(LoadService.java:421)
    at org.jruby.RubyKernel.requireCommon(RubyKernel.java:1088)
    at org.jruby.RubyKernel.require19(RubyKernel.java:1082)
    at org.jruby.RubyKernel$INVOKER$s$1$0$require19.call(RubyKernel$INVOKER$s$1$0$require19.gen)
    at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodOneOrNBlock.call(JavaMethod.java:350)

You'll notice that the file path it's trying to access is:
/Volumes/Big%20Data/Projects/acme/trunk/product/dependencies/jruby/jruby-complete.jar

But the actual path is:
/Volumes/Big Data/Projects/acme/trunk/product/dependencies/jruby/jruby-complete.jar

It looks vaguely like the code contains an assumption that you can just carve up a jar:// URL to get the path to the jar file inside it, but this turns out not to work if there is anything in the path which might be escaped. A space, I guess, is the most likely of these...

This is quite possibly another case of that bug in the File class with not resolving relative paths correctly, but this time it prevents me running any script.

[hakanai]

Should add that it's JRuby 1.7.6. I thought there might be a label for it, but it doesn't look like I have access to labels anyway.

[enebo]

@trejkaz Can you retry this now. I think we fixed this a couple of years ago and probably forgot to resolve this. I am closing but if it is still an issue then please re-open this.

[enebo]

Marked non-release because I think this was fixed so long ago it would strange showing up in release/changelog notes.