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.

Applet fails with AccessControlExceptions when running under JRE 7u21

I have a self signed applet, which was running fine till jre 7u21 came around.
Now I get the following AccessControlException when calling java.net.ProxySelector.setDefault:
Caused by: java.security.AccessControlException: access denied
("java.net.NetPermission" "setProxySelector")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.FXAppletSecurityManager.checkPermission(Unknown Source)
at java.net.ProxySelector.setDefault(Unknown Source)
For testing I tried removing this call, but other AccessControlExceptions start popping up. Apparently 7u21 applied significant changes to the applet's security model.
I always assumed that if the user accepts an applet's digital signature, no security restrictions apply. 7u21 now says that even signed applets can run in sandbox mode without clearly specifying when this is the case. (7u21 release notes). My security level slider in the Java control panel is set to medium (lowest level). Any recommendations how to resolve this?
Update: I resolved it by adding the security tag
<security>
<all-permissions/>
</security>
to the applet's jnlp file (applet is deployed via dtjava). It is now running under 7u21 without problems.

"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).

java applet java.security.AccessControlException: access denied java.net.SocketPermission

I friend of mine gave me a script to run minecraft skins on my site but i keep getting this error and i dont have any clue how to go about this... =(
http://allcitybuilder.com/new/example.html
java.security.AccessControlException: access denied (java.net.SocketPermission www.minecraft.net:80 connect,resolve)
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.checkConnect(Unknown Source)
at sun.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at net.minecraft.skintest.math.Zombie$1.run(Zombie.java:82)

You must allow the Applet to connect to a resource.
Have a look at the sigend Applet tutorial: http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html

Normally Applets are only allowed to access the host they came from (in your case allcitybuilder.com). Thus, you either have to put the file to view also to this host (or install a proxy there), or your applet needs additional privileges to have more access.
For the applet to have more access, it needs to be digitally signed, and the user needs to confirm the applet loading.
But there is no way to say "I need only access to minecraft.net" and for the user to grant you only this permission (without manual editing of policy files), so it is an "all or nothing". Also, if the user refuses, the applet may either run with usual applet permissions (on Sun's Plugin) or not run at all (on IcedTea).
With JNLP you can get a confirmation for the user for individual actions, but this is only for local access, no remote one.

Probably the easiest thing would be to copy the resources to your site, making sure you have been granted appropriate rights by the copyright holder.
Alternatively, the site may add a crossdomain.xml file to allow access to code loaded from non-same-origin sites.
It is possibly to sign the code to gain full access to the local machine. However, this requires the user to accept the risk and writing secure code is surprisingly difficult.

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.