This discussion is archived
1 2 3 Previous Next 31 Replies Latest reply: Apr 14, 2011 6:26 AM by 855366 Go to original post RSS
  • 15. Re: Getting access denied java.io.FilePermission since update 24
    841771 Newbie
    Currently Being Moderated
    Kudos to this suggestion re:doPrivileged!

    Had a couple functions in our applet throwing exceptions with update 24 and wrapped offending code in:

    java.security.AccessController.doPrivileged(new java.security.PrivilegedAction()
    {
    public Object run()
    {
    // your code here

    return (null);
    }
    });


    appears to resolve for now ... hoping for a fix in the framework.

    Edited by: 838768 on Feb 22, 2011 5:48 AM
  • 16. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    Funny thing is ... we have been running like this for years without a problem ... until Update 24.
  • 17. Re: Getting access denied java.io.FilePermission since update 24
    841035 Newbie
    Currently Being Moderated
    RJ, did you see the post about your entire app being loaded from the local file system, including the HTML and JS?

    Here is the evaluation from the deployment engineering team, if we've misunderstood your scenario please let us know, otherwise this bug will be closed.

    ====

    according the forum, the user is trying to implement offline mode with a browser http doc base and a local file path codebase in applet tag.

    In order to do offline mode, every bits needs to be on the local system, including the html/js loaded by the browser.

    If I understand the posting in forum correctly, they are trying to load the html via browser, using a http URL, e.g:

    http://your_host.com/applet.html

    And inside applet.html, customer have codebase pointing to c:\some_files

    This will not work due to security reasons. And most browser blocks this too, e.g:

    <img src="c:\some_pic.gif"/>

    won't load either by a browser, if the html is loaded via http://your_host.com/img.html

    So if customer want to use codebase with a local path, the browser html/js file itself needs to be loaded from the local file system too.
  • 18. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    Joe ...

    Where are you reading this response from the engineering team ?

    ====================================================

    What we do is "version" our applet and never download the applet to the user's hard drive unless it is a new installation or the version of the applet changes. When we do download the applet to the hard drive, we also create a file called Exc.props ... that contains the version number of the applet that was downloaded.

    In our "installl" html page, we load a local js variable with the current version of the applet. The "install" html page loads our "installer" applet. The installer applet knows the version number that is specified in the html and then compares that version to the version contained in the Exc.props file. If the versions don't match, then we download the latest version of our applet from the server. If the versions match, obviously we don't download the version from the server.

    Once the "install" applet is finished doing it's thing, we then load another "launcher" html page from our "install" html page ...

    window.location.replace("exc.html");

    It is the exc.html page that actually launches our applet. It is in that html page the we use the codebase param to point to the location, on the hard drive where the applet was downloaded. This is where the problem lies ... we are asking to run the applet from the hard drive and the exc.html that launches the applet is on the web server.

    What this does for us, or for our customers, is if the version of the applet, on the hard drive is current, we don't need to get/load the applet that is on the web server. This cuts down on network traffic considerably seeing that our customers can have as many as 20,000+ users running our applet, multiple times, during a months time.

    We have been running this way for years without problems ... until now.

    If I get rid of the codebase param ... all is cool because the html pages and the applets are in the same directory on the server, but the applet is being served each and every time a user runs our application. We are using pack200 compression on our applet, but it is still 1,405K in size and whatever little network traffic we can save for our customers is very important.
  • 19. Re: Getting access denied java.io.FilePermission since update 24
    841035 Newbie
    Currently Being Moderated
    I was posting the feedback from the engineer on my team that evaluated this report.

    Is our understanding of your situation correct?
  • 20. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    Thanks for following up on this Joe.

    Is the reason for this change (which caused this problem for me) to stop rogue applets from being loaded/run under these conditions ?

    Is it considered "more safe" requiring the html that launches an applet and the applet itself be in the same directory ? ... even if the applet is signed ?

    Our application is a client/server application. Once a user actually "logs in" to our applet, they have the option to create "offline" usage. When they do so, we do copy the exc.html page to the same directory, on the hard drive, where the applet was downloaded to.

    With that, they can load/run the exc.html on the hard drive while they are flying or don't have internet availability and the applet will run and they can input the information, save it to the hard drive as a "draft" and when they do have internet availability, they run the applet again (via the normal URL connection) and then submit their work to the server.

    Hope this info helps.
  • 21. Re: Getting access denied java.io.FilePermission since update 24
    thomasng Newbie
    Currently Being Moderated
    As long as the browser loads exc.html from the hard drive directly too, it will work. You can have the applet codebase points to the harddrive too in that case. (not using http://some_hosts.com/exc.html)

    Since you copy exc.html to the local drive too already, can you change the browser to point to that local copy of exc.html to start the applet for offline mode ?

    This is a well known security limitation for browser in general. e.g img tag in html behaves the same.
  • 22. Re: Getting access denied java.io.FilePermission since update 24
    841035 Newbie
    Currently Being Moderated
    Exactly, if the html and applet are both locally loaded you should be ok.

    OR you could deploy using JNLP (webstart) and Java will manage caching the app locally for you. The user can drag the JNLP to their desktop and won't even need to start a browser, unless you need to run in a web page.
  • 23. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    Joe ...

    Webstart is not the answer for us and I am sure a lot of other application too.

    So pretty much ... codebase has now been made useless ... you can't point to jar that is not in the same directory of the html page that loads it.

    So there really is no need to use codebase at all ... using it would be redundant, because we are now being forced to have both the html and applet in the same directory.

    If the applet is signed and the user has accepted the certificate ... what is the concern, security-wise ?
  • 24. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    I see that they have closed the bug report ... I'm not happy about that seeing that we are still discussing this.
  • 25. Re: Getting access denied java.io.FilePermission since update 24
    840426 Newbie
    Currently Being Moderated
    Let me put this in perspective from my point.

    Our application is an enterprise-wide solution being used by over 100 corporations (many Fortune 500 companies) and is deployed in over 85 countries. Depending upon the company, the amount of users can be from 500 to over 200,000 ... so this little change, which may seem trivial in some aspects, has thrown quite a wrench into the works as far as we are concerned.

    As users download (some automatically) Update 24, and our application stops dead in it's tracks, the noise level rises proportionately.

    I would still like to understand why the running of a signed applet, in the way I have described, is a security concern.

    If the applet, pointed to by the codebase, is not in the same directory as the html file that is loading the applet, and the applet is signed and the user has accepted the certificate ... then run it.
  • 26. Re: Getting access denied java.io.FilePermission since update 24
    635982 Newbie
    Currently Being Moderated
    We are a user of a Java application (which we don't have access to the source code) that has been working perfectly up until the last update of Java _24. Since the update we can no longer use the application. It appears the be the exact same issue discussed here. I do consider it a bug that needs to be fixed. It sounds like the changes made that broke this weren't well documented (if at all) in the release notes for the Java update and there isn't any easy fix other than rolling back to the previous version of Java.

    It has been asked several times on this thread and I too am curious what was the driving force behind the change in Java that broke the application we use all the time. Was it just that someone thought it wasn't a good idea and just decided to change it or is there a real security risk that had to be addressed? If so speak up.
  • 27. Re: Getting access denied java.io.FilePermission since update 24
    thomasng Newbie
    Currently Being Moderated
    The security issue is the html content loaded via http or https remotely by a browser, should not contain reference to any local file system. This is the security problem.

    e.g http://somehost.com/index.html

    if index.html contains <img src="c:\test.jpg">, browser will not load test.jpg for you, even if it's on the local system. This is the security problem, and all browser blocks that.

    That's the same reason why you cannot have <applet codebase="c:\applet" ...> in the index.html above.

    Whether the applet JAR in the local computer is signed or not does not matter. The problem is the remote page should not know about installed JARs on the system. Also, if we allowed that JAR on the local system, any other webpage can also use the JAR. This also enable malicious webpage to gain access to installed java applications.

    Application should not depend on this security hole to implement the feature they need. It is very likely that there are other ways to implement it and we will be happy to advise on the better approach.

    If you still have further questions regarding this issue, you can consider to use the official Oracle support channel, e.g:
    http://www.oracle.com/us/technologies/java/java-for-business-071123.html
  • 28. Re: Getting access denied java.io.FilePermission since update 24
    844271 Newbie
    Currently Being Moderated
    I'm getting "java.security.AccessControlException: access denied" since update 24, On my website Fatpaint.com.

    It uses a normal signed applet to access the user's local hard drive and to do some socket communication, all requiring privileged access. This worked fine before this update. The applet is loaded from the same server as the webpages.

    I used this method:

    SwingUtilities.invokeLater(new Runnable() {
    public void run() {
    //Do stuff.
    }
    });
  • 29. Re: Getting access denied java.io.FilePermission since update 24
    844271 Newbie
    Currently Being Moderated
    This code in a signed applet no longer works:

    public void openFileBrowser(String cmd, String filePath, String fileType) {
    this.filePath = filePath;
    this.fileType = fileType;

    info("LocalAccessMain, openFileBrowser(): cmd = " + cmd + ", filePath = " + filePath + ", fileType = " + fileType);

    fileBrowserCmd = cmd;

    final LocalAccessMain owner = this;

    SwingUtilities.invokeLater(new Runnable() {
    public void run() {
    owner.doOpenFileBrowser();
    }
    });
    }

    private void doOpenFileBrowser() {
    try {
    JFileChooser chooser = new JFileChooser(FileSystemView.getFileSystemView());
    chooser.setDialogTitle("Choose the file name");
    .......
    chooser.showSaveDialog(parent);
    .......
    } catch (Exception e) {
    }
    }

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points