Develop Reference

Additional Permission required if Java Console is open?

I've found an interesting behaviour in my Java Applet.
All seems to work fine, but when i have the Java Console Window the Applet does nothing and i can see the following exception to be thrown in the Java Console:
Exception in thread "Thread-33" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.deploy.uitoolkit.impl.awt.ui")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkPackageAccessHelper(Unknown Source)
(...)
So my question is now, why does the Application need more permissions when the console is open than when its closed? I've tried to google the permission but no one seems to have had any problems with this.

Can't get applet to read text file

I've tried to get my Java Applet to read from my text file, but I do not have sufficient privaleges to read the file when i run the applet in my browser.
I have tried to use policy files but I cannot seem to get them to work.
I later tried
System.setProperty("java.security.policy", "*filelocation*");
but i got this error
java.security.AccessControlException: access denied (java.util.PropertyPermission java.security.policy write)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.System.setProperty(Unknown Source)
at BIT.init(BIT.java:35)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
What ways can I get my applet to run in my browser? It works fine in Eclipse's applet viewer.

The reason is specified within the What Applets Can and Cannot Do. It clearly specifies that:
Applets that are not signed are restricted to the security sandbox,
and run only if the user accepts the applet. Applets that are signed
by a certificate from a recognized certificate authority can either
run only in the sandbox, or can request permission to run outside the
sandbox. In either case, the user must accept the applet's security
certificate, otherwise the applet is blocked from running.
Later it states that:
Sandbox applets cannot perform the following operations:
They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.
They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).
They cannot load native libraries.
They cannot change the SecurityManager.
They cannot create a ClassLoader.
They cannot read certain system properties. See System Properties for a list of forbidden system properties.
To know about how to sign an Applet look here : How to Sign Applets Using RSA-Signed Certificates

You really ought to consider signing the applet.
This (short!) FAQ discusses both policies and signing:
http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem
Here is the offician documentation:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/doprivileged.html
http://docs.oracle.com/javase/tutorial/deployment/applet/security.html
And here is a good (albeit old) tutorial:
http://faculty.kutztown.edu/spiegel/CSc421/SigningAnApplet.htm

Jena + Pellet + Slick in an applet

I am trying to integrate Jena libs, Pellet and some RPG 2d library Slick all together in an applet.
So basically when I run the applet in the browser I get this file permission error (the jars I am using are all signed):
Exception in thread "Thread-15" java.lang.ExceptionInInitializerError
at org.mindswap.pellet.ABox.<init>(ABox.java:208)
at org.mindswap.pellet.KnowledgeBase.clear(KnowledgeBase.java:540)
at org.mindswap.pellet.KnowledgeBase.<init>(KnowledgeBase.java:418)
at org.mindswap.pellet.jena.PelletInfGraph.<init>(PelletInfGraph.java:99)
at org.mindswap.pellet.jena.PelletReasoner.bind(PelletReasoner.java:95)
at org.mindswap.pellet.jena.PelletReasoner.bind(PelletReasoner.java:53)
at com.hp.hpl.jena.ontology.impl.OntModelImpl.generateGraph(OntModelImpl.java:2744)
at com.hp.hpl.jena.ontology.impl.OntModelImpl.<init>(OntModelImpl.java:139)
at com.hp.hpl.jena.ontology.impl.OntModelImpl.<init>(OntModelImpl.java:128)
at com.hp.hpl.jena.rdf.model.ModelFactory.createOntologyModel(ModelFactory.java:410)
at RPGGame.GameSelectionScreen.init(GameSelectionScreen.java:170)
at RPGGame.RPGGame.initStatesList(RPGGame.java:39)
at org.newdawn.slick.state.StateBasedGame.init(StateBasedGame.java:164)
at org.newdawn.slick.AppletGameContainer$Container.initApplet(AppletGameContainer.java:272)
at org.newdawn.slick.AppletGameContainer$ContainerPanel.initGL(AppletGameContainer.java:229)
at org.newdawn.slick.AppletGameContainer$ContainerPanel.start(AppletGameContainer.java:216)
at org.newdawn.slick.AppletGameContainer$1.run(AppletGameContainer.java:92)
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "pellet.configuration" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at org.mindswap.pellet.PelletOptions.<clinit>(PelletOptions.java:805)
Thanks in advance,
Ioana

The error is because ABox is trying to read information out of PelletOptions, which needs to load the Pellet configuration. It will usually try to read this out of the jar, but first, it double checks if the user specified in the system properties a different location than the default. It's this check that is causing the error.
You can just modify PelletOptions to always check in the jar and avoid the system properties check, or you might be able to twiddle the applet security stuff to make this ok (I don't know if that's possible, never used an Applet before).

"access denied" when using JDBC from a browser applet

I have a java applet that queries an Oracle database for data. When run from inside an IDE, it functions just fine. But when I run it as an applet embedded in a webpage, I get an "access denied" error in the class loader, and I haven't the foggiest notion what it is requiring of me:
Sep 06, 2011 12:58:48 PM oracle.jdbc.driver.OracleDriver registerMBeans
WARNING: Error while registering Oracle JDBC Diagnosability MBean.
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Thread.getContextClassLoader(Unknown Source)
at oracle.jdbc.driver.ClassRef.<init>(ClassRef.java:75)
at oracle.jdbc.driver.ClassRef.newInstance(ClassRef.java:51)
at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:311)
at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:195)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.binderton.oracle.ConnectionManager.open(ConnectionManager.java:17)
at com.sun.javafx.applet.FXApplet2$2.run(Unknown Source)
at com.sun.javafx.application.PlatformImpl$3.run(Unknown Source)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$100(Unknown Source)
at com.sun.glass.ui.win.WinApplication$1$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.binderton.oracle.ConnectionManager.open(ConnectionManager.java:17)
at com.sun.javafx.applet.FXApplet2$2.run(Unknown Source)
at com.sun.javafx.application.PlatformImpl$3.run(Unknown Source)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$100(Unknown Source)
at com.sun.glass.ui.win.WinApplication$1$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" getClassLoader")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Thread.getContextClassLoader(Unknown Source)
at oracle.jdbc.driver.ClassRef.<init>(ClassRef.java:75)
at oracle.jdbc.driver.ClassRef.newInstance(ClassRef.java:51)
at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:260)
... 12 more
Got ErrorEvent[url=null label=Failed to start application. cause=null

Applets runs in an environment with very restrictive security rules. You need at least to sign your applet.
But, the problem is bigger here, doing JDBC inside an applet is a very bad idea. The applet's source code is publicitly available and is thus sensitive for easy hacks. You should really create a webservice for that instead and then let your applet access that webservice instead. With a webservice, your applet will be able to exchange information with the DB by just HTTP requests/responses. With a webservice you hide the DB access details, JDBC and SQL code from the public.
How exactly to create a webservice depends on the server environment and the programming language used. In Java EE for example, you could already use a simple Servlet for this, but also JAX-RS and JAX-WS is supported for restful (XML/JSON) and XML webservices respectively. An applet is without any security restrictions allowed to connect with its host whose address is available by getCodeBase() E.g.
InputStream response = new URL(getCodeBase(), "servlet?foo=bar").openStream();
// ...

Note that if you follow the advice of BalusC and hide the DB behind a an active page (e.g. a servlet, PHP, ASP etc.) that is on the same server as the applet, the applet could most probably remain sand-boxed. It would be the active page that is trying to access class-loaders (as well as the DB).

Calling a DLL from an Applet via JNI

I have a "proof of concept" piece of work that crosses over into some unfamiliar territory.
I'm tasked with connecting an EFTPOS machine to an application running as an applet in a browser on our intranet.
I've ignored the EFTPOS dll for the moment and created a simple JNI decorated DLL in my language of choice (Delphi) that just logs a string to a text file in c:\ and I can call it successfully from a local Java application.
However, when I create an applet to do the same thing, compile it into a .JAR, sign the JAR & try to call the method in the applet via Javascript on a web page it fails.
A senior Java guy I'm working with doesn't think it will be possible to get this to work because it's inherently "evil" to allow an applet to do this.
There is an entry you can put in a java.policy file to allow loadLibrary. as well as allPermission & I've tried a whole host of variations along those lines all to no avail producing the following error trace in the Java Console:
java.lang.ExceptionInInitializerError
at app.TestApplet.LogAString(Unknown Source)
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)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
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)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at app.DLogger.<clinit>(Unknown Source)
... 16 more
java.lang.Exception: java.lang.ExceptionInInitializerError
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
The key line seems to be "Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.DLoggerImpl)" which implies a permissions problem. It could be that I'm getting the policy file wrong - or the signing wrong - or stuff like that or it could be that Java is hardwired to not allow those sort of permissions for an Applet because of the security risk.
My question is am I wasting my time? Can it be done & if so, how?
Thanks in anticipation
Mike

You can definitely accomplish this. I have a working applet in production that does exactly this. Even if your applet is signed, you still need to use the Access Controller to access the dll, you cannot just call "loadlibrary". You can add this to the Java policy file however this is not recommended due to 1. You probably do not have access to the users java configuration. 2. Even if this is for your own company use, managing the policy file is a pain as users will download some JRE and your policy file is either overwritten or ignored.
You best bet is to sign your jar, making sure to wrap your load library code in a privileged block of code like this.
try
{
AccessController.doPrivileged(new PrivilegedAction()
{
public Object run()
{
try
{
// privileged code goes here, for example:
System.load("C:/Program Files/.../Mydll.dll");
return null; // nothing to return
}
catch (Exception e)
{
System.out.println("Unable to load Mydll");
return null;
}
}
});
}
catch (Exception e)
{
System.out.println("Unable to load Mydll");
}
You can Also use System.loadlibrary(mydll.dll) but you have to have the dll folder on the path in windows so the applet can find it.
If you need some source samples for calling the JNI functions let me know I can grab that as well.

The only thing I can suggest is taking a look at the source code for that area and trying to decipher if it is not allowing because of lack of permission or because that is not allowed at all. You don't have line numbers unfortunately, so that makes it a little more tricky.

I am pretty sure you cannot load a native library from an Applet unless it is "signed", and then the user will get an acceptance dialog to allow or disallow. That is, assuming you can do JNI at all in an applet... never tried that.
Good luck.