JDK-4950874 : Deserialization of multiple Calendar objects fails under applet security manager
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.1,1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux,windows_xp
  • CPU: x86
  • Submitted: 2003-11-07
  • Updated: 2003-11-08
  • Resolved: 2003-11-08
Related Reports
Duplicate :  
JDK-4921945 - Cannot deserialize a Calendar with Security on
Description

Name: jl125535			Date: 11/07/2003


FULL PRODUCT VERSION :
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

FULL OS VERSION :
Linux xxx 2.4.20 #2 SMP Fri Sep 26 16:02:02 EEST 2003 i686 unknown
Microsoft Windows 2000 [Version 5.00.2195]
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
If the serialization stream contains more than one java.util.Calendar object, deserializing it under applet security manager throws a StreamCorruptedException. If it contains only one Calendar object it deserializes fine. The test case demonstrates the problem with two Calendar objects in an array. However, the same problem occurs also when the two objects are written separately (two writeObject calls) to the same ObjectOutputStream or when the Calendar objects are reachable from an ordinary (not an array) object that is written to the stream. This problem only occurs under the applet security manager, so normally one sees it only in the appletviewer and the Java Plug-in.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the given test case.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Test case should not throw an exception.
ACTUAL -
The test case throws a StreamCorruptedException when it tries to deserialize the Calendar object array.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.io.StreamCorruptedException
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1301)
        at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1603)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1271)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
        at Bug.main(Bug.java:11)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;
public class Bug {
    public static void main(String args[]) throws Exception {
        System.setSecurityManager(new sun.applet.AppletSecurity());
        Object[] o = new Object[] {
            java.util.Calendar.getInstance(),
            java.util.Calendar.getInstance()
        };
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        new ObjectOutputStream(baos).writeObject(o);
        new ObjectInputStream(new ByteArrayInputStream(
            baos.toByteArray())).readObject();
    }
}

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

CUSTOMER SUBMITTED WORKAROUND :
When you need to serialize time information, use some other representation for time than a Calendar.
(Incident Review ID: 217666) 
======================================================================
Comments
WORK AROUND Grant the "accessClassInPackage.sun.util.calendar" RuntimePermission to the code deserializing the Calendar instances.
11-06-2004
EVALUATION This problem does not have anything to do specifically with sun.applet.AppletSecurity--it is also reproducible with a vanilla java.lang.SecurityManager instance installed. The problem initially surfaces at line 1709 (using JDK 1.4.2 line numbers) of java.util.Calendar, where Calendar's readObject method is attempting to deserialize a sun.util.calendar.ZoneInfo instance. This triggers a check for the "accessClassInPackage.sun.util.calendar" RuntimePermission; when a security manager is installed (and the policy does not grant this permission), this security check fails. However, at line 1713, Calendar.readObject swallows any Exception thrown by the ObjectInputStream.readObject call, including security exceptions. As a result, the problem is not immediately visible--Calendar.readObject returns normally, as does deserialization of the first Calendar instance. Even though no exception has been thrown to the caller, though, the stream has been left in an inconsistent state--data for the ZoneInfo instance was never properly consumed, since deserialization of that instance halted abruptly with the security exception. Consequently, when the second ObjectInputStream.readObject call is issued, it starts reading midway through the data for the ZoneInfo instance, and correctly throws a StreamCorruptedException. At first glance, one possible solution would be to narrow the scope of the catch block at Calendar.java:1713 so that it allows security exceptions (as well as other clearly fatal exceptions?) to pass through to code further up the stack. Not being familiar with the original purpose of this catch clause, however, I'm not sure whether there are other issues involved. Reassigning to java/classes_util for further evaluation... ###@###.### 2003-11-07 This serialization problem has been fixed as 4921945. The test case in Description runs Okay with the fix. ###@###.### 2003-11-08
07-11-2003