I am using KDE and Firefox
On my PC I have an option to start-> system-> OpenJDK 1.8.0 Policy Tool
But when I click I get the message that the program does not exist
I have reinstalled Java, but this program is still missing.
How do I solve this problem?
Run it manually in a shell (Konsole, e.g.) via “policytool”.
Apparently the menu entry is “broken”, it tries to run BINDIR/policytool.
$ cat /usr/share/applications/policytool.desktop
[Desktop Entry]
Name=OpenJDK 1.8.0 Policy Tool
GenericName=OpenJDK 1.8.0 Policy Tool
Comment=Manage OpenJDK policy files
Exec=_BINDIR_/policytool
Icon=java
Terminal=false
Type=Application
StartupWMClass=sun-security-tools-PolicyTool
Categories=System;DesktopSettings;Security;
Version=1.0
You could of course also use the menu editor or a text editor to fix the Exec line (should be “/usr/bin/policytool”, or just “policytool”…).
Also, you should file a bug report at bugzilla.opensuse.org (against Java) so that it gets fixed.
The “policytool” command worked perfectly on a console.
Thanks for the tip.
But this tool does not do what I need.
I need Java to install a program that is on a website of the Brazilian government
It should be easy, but over here these ties are complicated by being made by people who do not care about the people in general.
To install the program, you must first download a Java application.
This Java application downloads and installs the program I need.
The download is successful but then the following error occurs:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:813)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:532)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:936)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2393)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:321)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:734)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:285)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:403)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:805)
... 2 more
Some people have said that this also happens with Windows and is “fixed”
, simply type “./ControlPanel” by opening a Java window and registering the address of the site that originates the program
Could you tell me how I can do the same inside Linux?
Finally I was able to find the Java configuration window installed with the OpenSuse repositories
Probably this solution is also suitable for other distros
I removed everything that refers to java that was installed via OpenSuse distribution
I installed the latest version of Java as instructed directly from Oracle
After many hours, I found the file that opens the java configuration console … Below is the link
/usr/java/jre1.8.0_161/sun_java.desktop
Now just make the settings …
I hope it passes to OpenSuse users
A FYI
The @OP found his solution which was to obviously install Oracle Java (The including Java Control Panel can configure how to handle unsigned applets)
openjdk does not have a similar Java Control Panel.
The current way to configure this is described in the following article
https://unix.stackexchange.com/questions/143805/running-unsigned-javaws-code
If you have to, or are willing to disable the security check altogether (not recommended, but if you have no other immediate solution)
https://velenux.wordpress.com/2017/06/07/workaround-for-javaws-jnpl-error-cannot-grant-permissions-to-unsigned-jars/
HTH,
TSU
The first link shows paths and files that do not exist in my PC… maybe they exist on Ubunto…
I made the suggested change in the second link but the problem remains the same …
I rebooted the PC after editing but it remains don’t run unsigned applets
Been awhile since I’ve looked at the details…
The files exist, but are in different locations in openSUSE…
So, for example the java security file isn’t in /etc/, for openjdk 1.8 the file is at
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/java.security
The settings in the second link can be made in this same file.
If there are other files you’re looking for, I recommend using the “locate” utility installed by the package mlocate.
And, if you can’t find any other files, just ask…
TSU
The problem with this approach is that your changes likely get lost when you install updates, though.
There is a /etc/java/security/security.d/ though where you could apparently put your additions (I’m not sure how exactly).
And this also seems to imply that it might respect /etc/java/security/java.security, if you create it.
That link is about IcedTea AFAICS (openJDK’s webbrowser plugin), which does come with a graphical config tool (as mentioned in a comment on that page), itweb-settings.
Regarding the paths mentioned there: yes, they do seem to be “wrong”, apparently the user settings are stored in ~/.config/icedtea-web/(security/) now.
And itweb-settings should create that if it doesn’t exist yet.
Correction: I just checked, and these files are actually marked as config files in openSUSE’s java packages:
wolfi@amiga:~> rpm -qc java-1_8_0-openjdk-headless
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/blacklisted.certs
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/java.policy
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/java.security
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/nss.cfg
So modifications to those files will in fact survive package updates.