0

I am writing a Java file uploader applet, but I simply could not figure the following issue out. (The uploader is very specialised, therefore we could not just use a stock solution). I have a self-signed applet, which I am trying to test locally, but I cannot get it to read local files. I have Permissions:all-permissions declared in the manifest.

If I add

<param name="permissions" value="all-permissions" />

to the applet tag , it throws

com.sun.deploy.security.BlockedException: User has denied the privileges to the code

If I avoid this, it throws

java.security.AccessControlException: access denied ("java.io.FilePermission" PATH_TO_FILE" "read")

BlockedException is thrown in the first case, even though when the Java plugin asks me about security issues, I always say "don't block", in order for this code to run.

Any ideas how I can test this? Or could you point me to an open source Java uploader applet implementation I could inspect? Of course, the deployed version of this software will be signed with a trusted certificate, but I need a means to test it....

Thank you!

Update

Here is what needs to be done:

Given a web application which we developed, this application needs a lot of small files from the local filesystem. So, we need to iterate over a directory structure and inspect files in order to find those that the web app needs. This is very cumbersome by hand, therefore we need to automate this.

I thought of two other approaches:

  1. JNLP-applet, however, its API can only display a FileChooser for single or multiple files, but not for a directory
  2. A plain old Java client application, which will find the files it needs and upload them to the server via an API. This client can then be launched via Java Web Start.
  3. ..Do you have any more ideas?
Community
  • 1
  • 1
Peter
  • 715
  • 1
  • 12
  • 23
  • I updated my JRE today, so I am using the latest version, and I have my Java Control Panel security level turned down to Medium. – Peter Jan 14 '14 at 21:07

3 Answers3

1

What you are trying to do is generally frowned-upon as this is exactly how systems are compromised with Java installed. The operation you want to do is privileged, you will need to run your code in a privileged mode, and, most likely, create a policy file to allow this to work on the client machine. There's a short, concise tutorial on http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem.

Now, please, this is actually a VERY BAD IDEA. Is there no way that you could rather write a JavaScript page that will perform this upload via some API call at all? That way, you are not bypassing the browser security to perform the upload.

The Java Applet approach is an out-dated, dangerous and down-right nasty solution, and no amount of signing, policy files or tweaks will make this a safe alternative. I'm a huge Java fan, but if there's one thing that gives me nightmares, it's the Java browser plug-in - there's just never a good reason for using it, not when you consider how incredibly unsafe it is. Of course, don't get me started on Flash...

Your idea of using a plain Java client, loaded via Web Start, seems to be the best solution. That way, once installed, your application would have full access to the underlying file system. Of course, this also opens up the debate of whether this is really a situation for using Java in the first place, but that's a whole other kettle of fish.

Ewald
  • 5,691
  • 2
  • 27
  • 31
  • Thank you for your answer. Using a policy file, which needs to be present on every client's PC is a bad idea. As I cannot enter a long text with line breaks here, I'll update the question with details on what I'd like to achieve. – Peter Jan 14 '14 at 22:30
  • @Peter - thank you for clarifying. As I said, it's a very bad idea :) The Web Start idea seems to be the best solution, and will give you the freedom and flexibility you require. While this might not feel like the slickest solution, it might just turn out to be the easiest to get working. – Ewald Jan 16 '14 at 11:04
  • Great! You won't believe it, but I've just ran into a problem that requires exactly the same solution - Java Web Start looks like the route we are going to go for now, as it's the quickest way to get a "native" client on each machine. – Ewald Jan 17 '14 at 04:41
1

to do this you have to sign your applet.

keytool -genkey -keystore myKeyStore -alias me

keytool -selfcert -keystore myKeyStore -alias me

jarsigner -keystore myKeyStore jarfile.jar me

MSaudi
  • 73
  • 7
  • I signed it like that but it still cannot access the local file system. Can it be the reason that 1) The applet itself is located on the local PC 2) I'm not using AccessController.doPrivileged()? – Peter Jan 14 '14 at 22:36
  • no this can't be the reason and i think sign is enough for your problem i made applet to access native api on the machine and sign was enough to do that. – MSaudi Jan 21 '14 at 13:32
  • add all permissions attribute in MANIFEST.MF file – MSaudi Feb 26 '15 at 11:30
0

A self signed applet working off a local server1 should be able to access the local file-system. It might be necessary to lower the security level in the Java Control Panel. Oracle is in a process of tightening the security of applets, so it will depend on which exact JRE version is loading the applet.

  1. It seems the security environment of an applet loaded off the local file-system is tighter than if it were loaded from localhost. See this answer for details.

I agree with your assessment that the the JNLP based file chooser is unsuited to this task. As you mentioned, it is for working with file resources, not directories. Even worse, I noticed a small applet that I had developed using the JNLP based file open services was throwing NullPointerException while browsing around, with associated odd visual behavior in the chooser itself. Totally inadequate.

As the top poster for applet questions, I strongly actually warn against embedding an uploader in a web page. The biggest problems:

  • It creates further problems with browser/JRE/JavaScript/applet interaction bugs
  • It creates a non-resizable GUI. There are ways to create a resizable applet, but last time I checked, they were not reliable across browsers.

So in the end, I recommend using a fully trusted (i.e. all-permissions) app. that uses either the Swing JFileChooser or a variant of the File Browser GUI opened from a free-floating, JNLP launched JFrame. If the use-case is simple enough, we might even be able to dispense with the frame itself, and (visually) go directly to the file chooser.

The 'free-floating' approach will not work in a web-app. that requires JavaScript interaction. If the web-app. requires that, we come back to 'applet', and that is where you'd look to use the doPrivileged(..) functionality you mentioned in a comment. The reason being that if a method is called programmatically by JS, the Java based security manager detects that some frames in the stack are not trusted (the JS), and therefore puts everything back in the sand-box - even if the Java code was originally trusted.

Community
  • 1
  • 1
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433