Defeating JNLP security block for native DLL I/O
843802Jul 24 2002 — edited Feb 27 2005We are using JDK 1.4 and JWS 1.0.1. We have a Java GUI that calls (among other things) a JAR that has some C code for I/O that reads and writes to the user's hard drive. All the JARs are signed. We have the JNLP permissions set to "all" in the .jnlp file.
This should allow total access to the hard drive. Well, the Java code can access the hard drive, but the native C code in our DLL cannot touch it. The application works fine, letting the C code read/write to the computer's hard drive when the application is run from the command line, and also when the entire project is run within JBuilder 7. The problem is JNLP's security restriction.
When we launch the same app using JNLP, it just closes the window and exits with no message (using Web Start 1.01), or else it just does nothing and simply ignores the attempt to read or write the file (using OpenJNLP). The similar behavior of Web Start and OpenJNLP makes us belive that this behavior is part of the JNLP API, but it does not seem to be documented by Sun. We cannot find anything in the Sun documentation or bug list for Web Start that says anything about blocking native compiled code (and then included in a signed JAR) from doing I/O on the user's hard drive.
How can we turn off this undocumented security "feature"? It is making the deployment of our program with JNLP impossible. We wanted to run it on the client side, but if we cannot do that with the existing code, we will be forced to try to convert our application to a servlet and run it on the server. That would be a lot less work than rewriting the C code into Java. We cannot afford to rewrite 3000 lines of this C code into Java ... because it's fossil code that's C89 and it works fine.
Is Sun "pulling a Gates on us" by preventing anything but Java from doing I/O when it's deployed with JNLP? We are having the C code call the javax JFileChooser, and it lets us browse the hard drive to select any local file. But JNLP (and the JVM) is preventing it from reading or writing. This is strictly a Web Start/JNLP problem. Our Java app works fine when we don't launch it using JNLP.