Warning on Permissions attribute when running an applet with JRE 7u45

Question

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.

Try an explicit code base. I read another applet question that suggested the OP was having difficulty getting it to work as advertised. — Andrew Thompson, Oct 16 '13 at 10:01
*"I run the applet locally"* Look at the address bar in the browser, it should show the URL form of the HTML, if not the Jar. Use that address instead of `*`. — Andrew Thompson, Oct 16 '13 at 13:32
The URL is a file URL, and I don't think it works the same as normal HTTP URL. Besides, this Jar will eventually be deployed to server, so I expect it runs both locally and remotely. Any other choice do I have except using the documented but not-working "*"? — Zhao Yi, Oct 16 '13 at 13:39
Since 1.7 r51 this is stopping a VPN app to execute on my Mac. Sad sad. — Georg, Jan 15 '14 at 10:07
My experiences today suggest that if a jar file is blocked for a user because it doesn't satisfy the security policy, it may remain blocked for that user even after it has been updated to correct the problem. Try testing with a different user account, or wipe the user profile for your test account. — Harry Johnston, Feb 07 '14 at 02:20

Sisco Casasempere · Answer 1 · 2014-04-16T13:25:04.953

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.

score 2 · Answer 2 · answered Nov 11 '13 at 11:37

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.

score 2 · Answer 3 · answered Sep 17 '14 at 16:22

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.

score 1 · Answer 4 · answered Nov 05 '13 at 19:29

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.

Thanks, that's definitely very useful to know. So in addition to re-signing all of our third-party jars, we also have to tweak the manifests in each of those jars. :I — JimN, Nov 07 '13 at 00:09

score 1 · Answer 5 · answered Jan 15 '14 at 10:21

1

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:

Screenshot of the dialog (it's in German, sorry!)

answered Jan 15 '14 at 10:21

Georg

987
8
16

2

This option does not exist with Java 1.7_45. – Justin Skiles Mar 28 '14 at 13:13

score 0 · Answer 6 · answered Oct 16 '13 at 17:50

0

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:

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.

answered Oct 16 '13 at 17:50

Tom Hawtin - tackline

145,806
30
211
305

2

In my development environment, I only have a self-signed certificate at present for testing-purpose. How can I make sure what I do is correct before signing with a trusted certificate? – Zhao Yi Oct 17 '13 at 02:10
Now I've also tested with a trusted certificate, but the applet is still blocked if Permissions is set to all-permissions. Sandbox works but that's not what I want. – Zhao Yi Oct 21 '13 at 09:58
1

The OP is using 7u45, not 7u51 which raises the security baseline. 7u45 doesn't require a cert from a trusted authority. – JimN Nov 07 '13 at 00:07
@JimN 7u51 is the "in the future" of 7u45. – Tom Hawtin - tackline Nov 07 '13 at 00:16
1

@ZhaoYi Create your own certificate authority, use it to sign a certificate and add the CA's cert to your trusted cacerts file. This makes the JRE treat the cert treated as if it's issued by a trusted authority. It's the "correct" way to test without proper certs. – Jacob Zwiers Jan 29 '14 at 18:03

bnicer · Answer 7 · 2013-11-11T17:27:49.997

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.

I was having this situation, which appears to be the third from last "Known Issue" in the [release notes](http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html). Using a `jnlp` file gave a different error, but using a `jnlp` along with `deployJava.js` seems to have fixed things for me. — Teepeemm, Dec 23 '13 at 14:32

score 0 · Answer 8 · answered Nov 08 '13 at 09:34

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: *

JimN · Answer 9 · 2013-11-11T23:46:32.043

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.

score 0 · Answer 10 · answered Jan 21 '14 at 17:37

0

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

answered Jan 21 '14 at 17:37

Noel

437
6
9

1

This doesn't address the question at all. – Justin Skiles Mar 28 '14 at 13:15

score 0 · Answer 11 · answered Feb 13 '14 at 13:12

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.

score -2 · Answer 12 · answered Feb 20 '14 at 22:03

-2

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

answered Feb 20 '14 at 22:03

andya

1

Warning on Permissions attribute when running an applet with JRE 7u45

12 Answers12

Linked