Topic: Defeating Java security to let a JNLP-launched application do I/O with C code compiled into a DLL and then encapsulated in a signed JAR?

Defeating Java security to let a JNLP-launched application do I/O with C code compiled into a DLL and then encapsulated in a signed JAR?

1 posts in topic

Flat View

Thread View

Older Post First | Reply to Topic

TOPIC ACTIONS:

Print Topic

Posted By: David_Chanin
Posted On: Tuesday, July 23, 2002 08:55 PM

We are using JDK 1.4 and JWS 1.01. 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, our 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 it 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.

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 Java FileChooser and it lets us browse the hard drive to select a file. But JNLP (and the JVM) is preventing us from reading or writing it. This is strictly a Web Start/JNLP problem. Our Java application works fine when we don't launch it using JNLP.

Arggh!

<<Less

Report | Quote This | Send private message | Reply | Print

Re: Defeating Java security to let a JNLP-launched application do I/O with C code compiled into a DLL and then encapsulated in a signed JAR?

Posted By: David_Chanin
Posted On: Thursday, July 25, 2002 09:46 PM

CORRECTION: I incorrectly said in my initial post that: "We are having the C code call the javax JFileChooser, and it lets us browse the hard drive to select any local file."
Instead, we're using javax.jnlp.FileOpenService.

We have only one DLL and we know it is being loaded because the function returns parameters correctly.
However, if the function is allowed to proceed to the first file operation (C file operation "fopen"), it exits without diagnostic (with Web Start 1.0.1) or simply does a no-op (with OpenJNLP). The fact that it fails to work with both WebStart and OpenJNLP seems to mean that it's a security problem or a bug in the JVM (JRE 1.4.0) ... or an undocumented security feature of the JNLP API.

Furthermore, the application works correctly outside JNLP, and all jar files have correct signatures (keygen). After invoking JNLP from command line with javaws, Java can successfully open and read from files.

We are not using the Java FileChooser as i said in my first post. What the code is actually doing is this:

FileOpenService fos;
fos = (FileOpenService)ServiceManager.lookup("javax.jnlp.FileOpenService");
FileContents fc;
fc = fos.openFileDialog(null, null);
String FileName = new String("");
FileName = fc.getName();

'FileName' is what gets passed into the C code. Java can successfully use 'fc' for file I/O in JNLP. Java can NOT use 'FileName' with java.io.FileInputStream for file I/O. Passing the string 'FileName' into the C code fails only after the first file operation (fopen), not anytime before.

Why won't Java 1.4 (under JNLP with "

") let our native DLL read and write to local files on the hard drive that the FileOpenService lets us select?

Report | Quote This | Send private message | Reply | Print