Although appletname is signed, runtime.getruntime(cmd.exe C (CMD) exception: Java. Security. accesscontrolexception: Access Deni

Note: This article is from the blog "afei". If you want to repost this article, please contact the author! And indicate the source: http://blog.csdn.net/faye0412/article/details/7037078

In the past two days, I suddenly received a feedback from the CS department, saying that a project had a problem. Look at it, oh, it turned out to be an applet project a few years ago, no matter which browser is used on the client, it cannot run normally. I checked the exception information as follows:
Java. Security. accesscontrolexception: Access Denied (Java. Io. filepermission "<all files>", "execute ")...
... <Other information omitted>

This problem was also encountered during development. It was solved after the signature was completed, but why did it come up recently? Strange ....

I found another N machines, and I found a problem in different browsers (IE7, 8, 9... cheome, Firefox:

1. It has nothing to do with the browser, but with the JRE version;

2. JRE Versions later than 1.6.0 _ 20 cannot run normally. Any version earlier than 1.6.0 _ 20 can run normally (My JRE version is 1.6.0 _ 29-b11 and cannot run );

How can this problem be solved? So I found n related documents in Oracle, such:

Http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html (Signature applet)

Http://docs.oracle.com/javase/1.4.2/docs/guide/security/permissions.html (permissions in the javatm 2 SDK)

No progress. I tried the following method:

1. Methods for defining private policy files;

2. Modify the Java default security policy file (not secure), $ {java. Home}/lib/security/Java. Security file, and add the authorization method;

It didn't work (maybe I didn't get it right ?), However, we cannot allow every customer to modify their own security policy files. After all, not everyone is so professional, and customers are not willing to accept this approach.

Solution:

Later, after reading the document, I found an important method to quickly solve my problem, that is, using accesscontroller. doprivileged to improve code permissions! If you do not want the client to modify the security configuration in the JRE, you can upgrade it in the code, which is what I expect!

In the JDK dialog box popped up on the client, you only need to click "trust" and "run". That is to say, if you trust this signature, you can execute this code: accesscontroller. doprivileged (...), the applet permission will also be improved.

The sample code is as follows:

private String runCmd(){String result = AccessController.doPrivileged(new PrivilegedAction<String>() {          @Override          public String run() {            String res = null;//TODO like 'Runtime.getRuntime().exec(cmd)' etc.....                return res;              }        });return result;}

In this way, a few simple words can be done ....

Don't forget, the last thing you need to do is re-create the jar package, sign the package, and then re-release the certificate, keystore file, JAR file to the server for testing :)

Supplement:

I have also written an article about the JS call Applet Execution permission issues (http://blog.csdn.net/faye0412/article/details/4566400), which mentioned the use of swingutilities. invokelater (New runnable ()... but this method can only solve the problem of the previous signature and Applet false, and cannot solve the current situation, so the best way is to combine these two methods. Perfect solution to the problem !!