> From: andreas [mailto:[email protected]]
> Subject: Re: Tomcat 6.0.20, JDK1.6.0_14 and security manager
>
> But I wonder what this means in terms of security?
Konstantin's suggestion should not be a problem. Note that code in Tomcat's
lib directory is given all permissions (by default), but only bootstrap.jar and
commons-daemon.jar from Tomcat's bin directory also enjoy the same privilege.
Here's the new code in 6u14:
private Cleaner() {
/* Set context class loader to null in order to avoid
* keeping a strong reference to an application classloader.
*/
this.setContextClassLoader(null);
}
The reason the AccessControlException is thrown is because of the following in
http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html
"whenever a resource access is attempted, all code traversed by the execution
thread up to that point must have permission for that resource access"
Despite the fact that code from rt.jar is given all permissions, code that
calls methods in rt.jar is not unless explicitly granted by the security
policy. The setContextClassLoader(null) call has to be in the constructor
rather than the Cleaner's run() method since this subclass of Thread doesn't
actually execute until the JVM is shut down; wiping out the reference to any
existing classloader copied from the caller's current Thread must occur early
to allow GC to clean out webapps that have been undeployed.
Looks like Sun simply forgot to document this security incompatibility
introduced in 6u14.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
