Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
ServletExec Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 143
Product ServletExec
Category Miscellaneous, XML
Question I am getting java.lang.SecurityException: sealing violation. Why ?
Answer New Atlanta has never seen this problem here, but has had a handful (2 or 3) of customers report it.
We believe that the problem occurs when you have classes that are part of the same package,
and some of those classes are in one JAR file, and some are in another JAR file
and at least one of the JAR files has been "sealed" as described at:
http://java.sun.com/docs/books/tutorial/ext/security/sealing.html
Here is the text we found at that link (as of 12.18.2001):
Sealing Packages in Extensions

You can optionally seal packages in extension JAR files as an additional
security measure. If a package is sealed, all classes defined in that package
must originate from a single JAR file. 
Without sealing, a "hostile" program could create a class and define it to be
a member of one of your extension packages. The hostile software would then
have free access to package-protected members of your extension package. 
Sealing packages in extensions is no different than sealing any JAR-packaged
classes. To seal your extension packages, you must add the Sealed header to
the manifest of the JAR file containing your extension. You can seal individual
packages by associating a Sealed header with the packages' Name headers. A
Sealed header not associated with an individual package in the archive signals
that all packages are sealed. Such a "global" Sealed header is overridden by any
Sealed headers associated with individual packages. The value associated with the
Sealed header is either true or false. 

Examples:

Let's look at a few sample manifest files. For these examples suppose that the
JAR file contains these packages: 

com/myCompany/package_1/
com/myCompany/package_2/
com/myCompany/package_3/
com/myCompany/package_4/

Suppose that you want to seal all the packages. You could do so by simply adding
an archive-level Sealed header to the manifest like this: 

Manifest-Version: 1.0
Sealed: true
All packages in any JAR file having this manifest will be sealed. 

If you wanted to seal only com.myCompany.package_3, you could do so with
this manifest: 

Manifest-Version: 1.0
Name: com/myCompany/package_3/
Sealed: true

In this example the only Sealed header is that associated with the Name header
of package com.myCompany.package_3, so only that package is sealed.
(The Sealed header is associated with the Name header because there are no blank
lines between them.) 

For a final example, suppose that you wanted to seal all packages except for
com.myCompany.package_2.
You could accomplish that with a manifest like this: 
Manifest-Version: 1.0
Sealed: true
Name: com/myCompany/package_2/
Sealed: false

In this example the archive-level Sealed: true header indicates that all
of the packages in the JAR file are to be sealed. However, the manifest
also has a Sealed: false header associated with package com.myCompany.package_2,
and that header overrides the archive-level sealing for that package.

Therefore this manifest will cause all packages to be sealed except for
com.myCompany.package_2. 

One New Atlanta customer saw this problem when using JDK 1.2.2_06. That customer reported to us that the problem disappeared after they upgraded to JDK 1.2.2_09. Sun's Bug database reports a bug which seems to fit this problem:
http://developer.java.sun.com/developer/bugParade/bugs/4401293.html
Another customer reported this problem when using SE 4.1 with JDK 1.2.2_06 and said that upgrading to JDK 1.2.2_09 did not help them (as it did with the earlier customer).
For this 2nd customer, we suggested that they examine ALL jars that are getting used by the JVM (which may not show up in the output that tells you your Classpath). Another FAQ at this site tells how to track down these JARs.
This tip helped that 2nd customer to find the solution.
Here is what they said:
In the directory java.ext.dirs there was an old xml.jar. That causes the problems with the crimson.jar. The class org.w3c.dom.DOMImplementation in the old xml.jar does not contain the method createDocumentType


crimson.jar is a JAR that comes with SE 4.1 which SE uses to parse XML files (web.xml, .tld files, etc...) The version of crimson.jar that comes with SE 4.1 is Crimson 1.1 and its manifest file contains "Sealed: true" SE 4.1.1 comes with crimson 1.1.3 which uses "Sealed: false"
So upgrading to SE 4.1.1 may be yet another way to solve this problem.



   
company media information terms of use privacy policy contact us