United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6785446 Java caches JAR files loaded w/URLConnection, then denies access to the cache
JDK-6785446 : Java caches JAR files loaded w/URLConnection, then denies access to the cache

Details
Type:
Bug
Submit Date:
2008-12-16
Status:
Closed
Updated Date:
2013-01-10
Project Name:
JDK
Resolved Date:
2009-05-13
Component:
deploy
OS:
windows_xp
Sub-Component:
deployment_toolkit
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,6u10
Fixed Versions:
6u14 (b03)

Related Reports
Duplicate:
Relates:

Sub Tasks

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.
                                     
2009-02-17



Hardware and Software, Engineered to Work Together