views:

64

answers:

1

There should be no security restriction because the applet is locally installed.

Yet I get:

java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.jzmq)

when my app tries to call

static{
     System.loadLibrary("jzmq");
}

What gives? What am I missing for it to work smoothly without a security question (as it should since it's a user-installed local applet)?

By the way it works fine from Eclipse "Run", just not in a browser, where I want it to run.

+1  A: 

Applets run via browser plug-in from the local file-system (file:///) are subject to almost exactly the same security checks as applets loaded from the web. The difference being that applets loaded from the web have the permission to "call home", ie. connect back to the server the applet originated from, and applets loaded from the filesystem have the permission to access the files in the same folder.

The sandbox by default does not permit loading native libraries in either case.

You could consider signing the applet. The user will have to OK the security dialog. And unless you have a code-signing certificate purchased from a certificate authority the dialog will warn the user of the fact that it's not signed by a trusted party.

I didn't fully understand your use-case, but if you can run other code on the local machine, you could always alter the java security policy in order to trust a .jar file in some specific local location. This way no security dialog gets presented.

To do this, you alter the java policy file, which on a windows machine with Java 6 would probably be in:

%PROGRAM FILES%\Java\jre6\lib\security\java.policy

And add a new permission, something like this:

grant codeBase "file:///path/yourcomponent.jar" {
      permission java.lang.RuntimePermission "loadLibrary.jzmq";
};

EDIT: To give full permissions, you could add a permission like this (this is copied from a succesful test I did just now):

grant codeBase "file:///C:/component/policytest.jar" {
      permission java.security.AllPermission;
};
Sami Koivu
Your last solution sounds perfect for what I'm doing. It doesn't seem to work. The applet doesn't have to be signed for this, yes? Are you sure its should work? Does the computer have to be restarted after editing the file? Or do I have to recompile the jar or classes after editing the file?
Navigateur
Correct, the applet does not need to be signed. The principle works, I've never tested with the loadLibrary permission, for debugging you could also grant AllPermission, which allows the applet to do everything. No need to recompile. In my experience restarting the browser (closing all browser windows) is sufficient.
Sami Koivu
Things to note: Prefer forward slashes on the paths. The path on the grant line must match the path of your .jar and your applet tag must reference that same .jar with an "archive" param. If you are not using a .jar, and instead one or more loose .class files, you could probably put something like this on the grant line: grant codeBase "file:///path/where/classes/live/-" (with the minus sign at the end for recursive subdirectories)
Sami Koivu
Awesome!! Your first example DID work!! (I simply picked the wrong java.policy file from the jdk lib folder instead of "jre6"). Do these policies change back to default when they update Java, making my changes useless? Or do they remain permanent on the user's computer? Can I make a Windows "install" program to do these policy changes automatically when they install my software? Would I have to find this "java.policy" file by brute force or is there a simpler command?
Navigateur
Excellent questions, unfortunately I don't have the answer to any of them.
Sami Koivu