JDK-6785446 : Java caches JAR files loaded w/URLConnection, then denies access to the cache
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6,6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-12-16
  • Updated: 2013-01-10
  • Resolved: 2009-05-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u14 b03Fixed
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
Java Plug-in 1.6.0_10

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
If an unsigned applet loads a JAR file using a URL connection, it succeeds the first time and places the file in the cache.  Subsequent loads fail with AccessControlException trying to read the file from the cache.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the applet below and place the class file on a web server

2. Place the HTML file in the same directory on the web server:

3. Put a file into the folder with the name test.jar

4. Visit the applet on that server from IE or Firefox, view the Java Console

5. Close the browser

6. Open the browser, and visit the applet again, view the Java Console



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Step 4 will print a message to the console showing that it was able to read the .JAR
Step 6 SHOULD print the same message
ACTUAL -
Step 6 throws the exception



ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\User\Application Data\Sun\Java\Deployment\cache\6.0\41\709d85a9-4c3f90f4.idx read)
	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.checkRead(Unknown Source)
	at java.io.RandomAccessFile.<init>(Unknown Source)
	at com.sun.deploy.util.SyncFileAccess.openLockFileObject(Unknown Source)
	at com.sun.deploy.util.SyncFileAccess.openLockRandomAccessFile(Unknown Source)
	at com.sun.deploy.cache.CacheEntry.openLockIndexFile(Unknown Source)
	at com.sun.deploy.cache.CacheEntry.readManifest(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.isUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.DeployCacheHandler.get(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at TestCacheApplet.start(TestCacheApplet.java:29)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
--TestCacheApplet.java--

import java.applet.*;
import java.net.*;
import java.io.*;

public class TestCacheApplet extends Applet
{
    public void start()
    {
        System.out.println("Reading...");
        try {
            URL u = new URL(getCodeBase(), "test.jar");
            //
            // Workaround #1: Do not use .jar extension...
            //
            // URL u = new URL(getCodeBase(), "test.jxr");
            //
            // Not good because many web servers will not serve up
            // files with unknown extensions, and many users cannot
            // influence the configuration of corporate web servers.
            //
            URLConnection uconn = u.openConnection();
            //
            // Workaround #2: Disable caching
            //
            // uconn.setUseCaches(false);
            //
            // Not good because caching is very useful!
            //
            InputStream istr = uconn.getInputStream();
            ByteArrayOutputStream ostr = new ByteArrayOutputStream();
            istr = new BufferedInputStream(istr, 16 * 1024);
            byte [] b = new byte[1024];
            int read;
            for(;;)
            {
                read = istr.read(b,0,1024);
                if (read == -1)
                    break;
                ostr.write(b, 0, read);
            }
            istr.close();
            System.out.println("Read "+ostr.toByteArray().length+" bytes");
        } catch (Exception ex) {
            System.out.println("Failed...");
            ex.printStackTrace();
        }
    }
}


--index.html--
<html><head></head><body><applet code='TestCacheApplet' width=1 height=1></applet></body></html>


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
1. Use a different extension.  This bug seems peculiar to .JAR files

2. Disable caching in the code, as shown above

3. Disable caching in the Java Control Panel

Comments
EVALUATION Original problem should not be reproducible after fix for 6791250 as we do not use readManifest directly from the Cache. However, there are some public methods in the CacheEntry, such as getManifest(), etc. that may try to read files on disk again in non-priveledged mode. We should wrap all public calls that may lead to disk access with priveledged action. Also, some of package private methods of CacheEntry better to be private to avoid introduction of direct requests in the future.
17-02-2009