JDK-4224921 : ClassNotFoundException deserializing standard extension obj containing app obj
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 1.2.0,1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic,solaris_2.5
  • CPU: generic
  • Submitted: 1999-03-29
  • Updated: 2006-12-14
  • Resolved: 2006-12-14
Related Reports
Duplicate :  
JDK-4337501 - ObjectInputStream.resolveClass() and ExtensionClassLoader problem
Relates :  
JDK-4932376 - IOException on drop part of drag'n'drop
Description
The Java Cryptography Extension (JCE) 1.2 is a standard Java extension
(see http://java.sun.com/products/jce).

In JCE 1.2, we provide a class named javax.crypto.SealedObject which
allows you to protect the condifentiality of any serializable object
by encrypting its serialized contents. The SealedObject constructor
takes 2 arguments: the object to be sealed (must be serializable), and
a Cipher object initialized for encryption. In the constructor
implementation, we serialize the object that was passed to the
constructor and encrypt its serialized contents with the Cipher
object.

This works fine if we seal objects of "standard" Java classes, but it
fails if we try to seal objects of custom Java classes. When we seal
an object of a custom Java class, and later try to unseal it, a
ClassNotFoundException is raised.
Comments
EVALUATION Serialization is paralleling the decision that the standard extension class loader should not delegate to the application class loader. So no action should be taken for this request.
14-12-2006
WORK AROUND Override ObjectInputStream.resolveClass() to use the application class loader to find application classes. This could be made easier with in ObjectInputStream with a constructor or method that would allow the ClassLoader to be used to be specified more easily.
23-07-2004
SUGGESTED FIX This should not get fixed. Serialization is paralleling the decision that the standard extension class loader should not delegate to the application class loader. This bug entry is a placeholder until this can be placed into a FAQ.
23-07-2004
PUBLIC COMMENTS Q: How should a standard extension deserialize application classes? A: The current technique is to create a classloader which gets the ContextClassLoader and delegates to it as appropriate. Q: Why is it this way? A: When the Standard Extension class loader was designed it was decided that standard extensions by default should only have visibility to other Standard Extension classes and system classes. This extends the security motivated invariant of system classes that they should by default only be able to refer to other system classes. When Thread.getContextClassLoader() was introduced late in JDK1.2 it would have been possible to delegate resolving classes to that class loader. However, this would pose a security risk to Standard Extensions because they (in general) not would be aware of the source of classes or of potential consistency problems with the name space. If the Standard extension is aware that it is operating on behalf of an application, either the application will supply the classloader to use or it can explicitly establish the class loader with which to resolve class names. It may use the getContextClassLoader method to find the applications classloader. Object deserialization followed the same security sensititive pattern. It uses the first non-null classloader of the caller. In a standard extension this will find the Standard Extension class loader thereby maintaining the security invarient. If the standard extension is aware that it is operating on behalf of an application it should establish the appropriate class loaders before deserializing the object. This could be made easier with in ObjectInputStream with a constructor or method that would allow the ClassLoader to be used to be specified more easily.
23-07-2004
EVALUATION The "latest non-null class loader" class resolution algorithm currently employed by ObjectInputStream.resolveClass() does have drawbacks as stated in the description for this bug. The question of what algorithm should instead be employed merits further consideration. Nevertheless, several factors weigh against the immediate resolution of this bug: 1. An accepted (though somewhat inconvenient) workaround exists--ObjectInputStream can be subclassed and its resolveClass method overridden to resolve classes according to some alternative algorithm. API changes (such as the addition of an ObjectInputStream constructor accepting a ClassLoader to resolve against) do not appear to offer any advantage over the existing workaround (other than convenience). 2. The "correct" class resolution algorithm (if one exists) is not known at this time. 3. Changing the default class resolution algorithm raises compatibility questions. Such action should not be undertaken without a clear notion of a better solution, and of the risks involved in switching to that solution. This bug will be kept open as a placeholder; however, no immediate action on this bug is planned at this time. michael.warres@east 2000-09-20
20-09-2000