Warning on Permissions attribute when running an a

问题:

I've just upgraded JRE to 7u45, and my applet receives a warning message on start-up, saying " This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute." Then I added the following two attributes to the manifest of my applet Jar file (self-signed):

Permissions: all-permissions
Codebase: *

However the warning message didn't disappear. I doubt that I'm missing some other things, but can't find them out after hours of research. Anybody else knows the solution?

Update

Trusted applet that is signed with a valid certificate can't run either. The yellow warning message doesn't show up but another error dialog is displayed saying the applet is blocked by the security settings, while changing the security level or something else in Java Control Panel doesn't help.

回答1:

I have the same problem. I test it with a explicit codebase, but the warning "Missing Permissions manifest attribute" it continues appearing.

Also tried changing permissions to "sandbox", the message still appearing but the applet don't have privileges to execute some functions.

Edit:

Finally I've found the solution: manifest.mf

Manifest-Version: 1.0
Codebase: *
Permissions: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Application-Name: AppName
Created-By: AppCreator

I hope this help you.

回答2:

I was also facing this problem and i resolved this problem in my application by just adding the certificate as a "Secure Site" under java control center.

The error message ("The application will be blocked ... Permission attribute") is so misleading and it acts more like a generic error message and has nothing to do with Permissions attribute really present in the jars or not. This to me is a bug and hopefully java will fix it in the next release.

Exact steps to remove this error message:
1) javaws -viewer
2) Open Security tab
3) Clik on "Manage Certificates"
4) Select Certificate Type as "Secure Site"
5) Add the application certificate.

回答3:

After spending some time breaking my head on editing manifest (see how to config manifest with maven) and all those java configurations, I've found how it works:

To grant allPermissions with java 1.7+ you need to edit java.policy file.

Use the policytool to do that. At prompt command line:

policytool

see Oracle tutorial: http://docs.oracle.com/javase/tutorial/security/tour1/wstep2.html

Open the right policy file where your browser vm is executing. For me its in:

C:\Program Files (x86)\Java\jre7\lib\security\java.policy

Should load some CodeBase list. Click on it for edit or:

Add Entry

Leave CodBase blank for every location where code is running but you can put localhost or your stite if you want and signedBy blank for non signed jars/applets. Click Add Permission, then choose AllPermissions
I have CodeBase <ALL> and it java.security.AllPermission

Then save! java.policy and should get sucess message.

Done you can run non signed applet and acess disk files.

回答4:

In your Java control panel, change the security level to Very High, that way it will block the applet from running because it is missing the required Permissions attribute. Run your application, an exception will be thrown which will tell you which jar is missing the attribute.

I was under the impression that adding the Permissions attribute to the main jar of the applet would be sufficient but I just found out that even an ancillary jar can cause the issue. I will now add the Permissions attribute to all my jars.

Hope this helps someone.

回答5:

Add the base url to the list of secure sites (excepted from checks) in the Java control panel's security tab, that made my vpn launch again:

回答6:

From New security requirements for RIAs in 7u51 (January 2014) in the "Java Platform Group, Product Management blog":

As of 7u51, (January 14, 2014), your RIAs must be updated. [...]

RIAs must contain two things:

1. Code signatures from a trusted authority. [...]

So it would appear that using a self-signed certificate is the problem here.

I think it's clear that a self-signed certificate is not much use as an introduction for an end-user.

回答7:

In 1.7.0_u45 you will probably need to have both the Permissions and Caller-Allowable-Codebase attributes set:

Caller-Allowable-Codebase: * localhost 127.0.0.1
Permissions: all-permissions

see this diagram which explains the security popups

I'm setting my manifest attributes like this:

Application-Name: MyAppName
Implementation-version: %VERSION% 
Permissions: all-permissions
Caller-Allowable-Codebase: * localhost 127.0.0.1
Application-Library-Allowable-Codebase: *

回答8:

I don't know that my original answer (deleted) was wrong. The Permissions attribute in the manifest should not be ignored in a local applet, so, it's a bug.

There are similar known issues described in the 7u45 release notes. This must be related.

As to the original question: Codebase: * ?

Codebase: localhost

It works for http://localhost and it does not contradict file://localhost/C:/folder, which (on Windows) is the correct JNLP codebase syntax. The Codebase attribute in the manifest allows multiple entries. Adding localhost surely will have no adverse effects.

Update:

Manifest-Version: 1.0
Implementation-Title: MyApplet
Implementation-Version: applet build
Built-By: bnicer
Application-Name: Slide Show
Created-By: 1.7.0_45-b18 (Oracle Corporation)
Caller-Allowable-Codebase: *
Implementation-Vendor: MyFirm
Ant-Version: Apache Ant 1.9.2
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Built-On: 8 November, 2013 @ 13:40:10 GMT
Trusted-Only: true
Permissions: all-permissions
Main-Class: jtss
Codebase: www.mydomain.co.uk localhost 127.0.0.1 192.168.2.2

I believe that running an applet offline under 7u45 will make problems no matter what you put in a manifest, and that is very unfortunate.

As far as I can tell the older method of adding a .java.policy file to the local directory is just as pointless, and that too is unfortunate.

More Info:

(Concerning the bug?)

If the applet is signed, you have the option to import the public certificate (.csr, .p12, .cer) in the Java Control Panel: Security > Manage Certificates > User > Signer CA. Importing the certificate in the past ensured: A) the applet publisher was known. B) the security popup before running the applet in the browser would be removed.

• Web Start applications, ditto.

The difference is that now (7u45): A) the publisher is known. B) you receive a "... manifest does not contain the Permissions attribute" warning.

• Local applets only.

After the warning, it has been my experience, that the applet won't run.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
    at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.access$100(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
    at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    ... 14 more
Caused by: java.lang.NullPointerException
    at sun.plugin2.applet.Plugin2ClassLoader.loadAllowedCodebases(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.getPermissions(Unknown Source)
    at sun.plugin2.applet.Applet2ClassLoader.getPermissions(Unknown Source)
    at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    ... 18 more

A work-around, but by no means a fix, is to delete the certificate from the Signer CA store. On deleting the certificate (in desperation, as a last resort) the signed, local applet runs as follows: A) UNKNOWN Publisher, etc. B) you get a security dialog, and the missing Permissions attribute warning.

• None of the above applies to applets online.

Feel free to comment.

回答9:

If you happen to be using webstart with version-based protocol, there seems to be a bug with this which causes the Permissions attribute warning when it shouldn't. Once we removed the version attributes from our jnlp, and removed the version string from the jar filenames, the Permissions attribute warning went away.

Edit: I found this forum thread which discusses the matter: https://forums.oracle.com/thread/2594060.

回答10:

Run the java uninstall applet to remove old versions of java. http://java.com/en/download/uninstallapplet.jsp

回答11:

I had the same error when trying to open Dell iDRAC virtual console. This doesn't help if you want to get rid of the warnings in a proper fashion. But if you want to just run the application then for me the solution was to open Java Control Panel and in Security tab set Security Level to Medium.

After that I could run the application after accepting the warnings.

回答12:

I placed my Java Security to Medium, and now can access the program.