You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by andreas <an...@telia.com> on 2009/06/06 18:38:17 UTC
Tomcat 6.0.20, JDK1.6.0_14 and security manager
Hi!
Have anyone beside me had any issues with the software versions mentioned in the subject line?
First I thought it was my wacky setup, so I tried to "vanilla" directly from tomcat.apache.org, and it still fails.
NOTE : Running the same tomcat installation with JDK1.6.0_12 produces no errors.
This is what I get in 'catalina.out' with JDK1.6.0_14;
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
java.security.AccessControlException: access denied (java.lang.RuntimePermission setContextClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.Thread.setContextClassLoader(Thread.java:1351)
at java.util.logging.LogManager$Cleaner.<init>(LogManager.java:204)
at java.util.logging.LogManager$Cleaner.<init>(LogManager.java:198)
at java.util.logging.LogManager.<init>(LogManager.java:235)
at org.apache.juli.ClassLoaderLogManager.<init>(ClassLoaderLogManager.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.util.logging.LogManager$1.run(LogManager.java:164)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.<clinit>(LogManager.java:156)
at java.util.logging.Logger.getLogger(Logger.java:273)
at org.apache.juli.logging.DirectJDKLog.<init>(DirectJDKLog.java:71)
at org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:170)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:242)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:297)
at org.apache.catalina.startup.Bootstrap.<clinit>(Bootstrap.java:54)
Can't load log handler "1catalina.org.apache.juli.FileHandler"
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.util.logging.LogManager$3.run(LogManager.java:383)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.addLogger(LogManager.java:376)
at java.util.logging.LogManager$1.run(LogManager.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.<clinit>(LogManager.java:156)
at java.util.logging.Logger.getLogger(Logger.java:273)
at org.apache.juli.logging.DirectJDKLog.<init>(DirectJDKLog.java:71)
at org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
etc etc.. for all of the entries in 'logging.properties'.
My platform is Linux and the 64-bit version of the SUN JDK.
tomcat is started with;
JAVA_HOME=/opt/jdk1.6.0_14 bin/catalina.sh start -security
Something happened in the latest JDK-release, question is what... :)
Thanks...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Tomcat 5.5.23 disappearing web.xml on unstable NFS mount
Posted by Marco van Hattem <ma...@ciber.com>.
Hi,
I've got a redhat system where seemingly at random, some applications
are losing the WEB-INF/web.xml file. It looks like there is a problem
with the NFS mount where the application lives, but I don't understand
why the web.xml would disappear when there are timeouts on the nfs
mount.
The catalina logfile reports these errors:
log4j:ERROR Failed to flush writer,
log4j:ERROR Failed to flush writer,
java.io.IOException: Input/output error
<..and some more io errors>
and proceeds to unload the application. Is it possible that this
unloading also somehow deletes the web.xml file?
Thanks, Marco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Subject: RE: Tomcat 6.0.20, JDK1.6.0_14 and security manager
>
> if you can show whats the problem with your policy
> check $TOMCAT_HOME/logs/%HOSTNAME%.YYYY-MM-DD.log
> for details
Since the logging mechanism can't be initialized, there are no log files generated. (They're created, but not written to.) The OP already posted all the information available, and Konstantin posted the fix.
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by Martin Gainty <mg...@hotmail.com>.
if you can show whats the problem with your policy
check $TOMCAT_HOME/logs/%HOSTNAME%.YYYY-MM-DD.log
for details
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Sat, 6 Jun 2009 21:07:38 +0200
> From: anpa0508@telia.com
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 6.0.20, JDK1.6.0_14 and security manager
>
> Indeed it does.
>
> But I wonder what this means in terms of security?
> I admit that my knowledge of the policy files and security-permissions is very weak, and granting permissions to something that I do not understand scares me a bit.
>
> Maybe I should file a bug about this and let it get investigated by someone who knows.
>
> Caldarale, Charles R wrote:
> >
> > I just verified that does correct the problem.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009
RE: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: andreas [mailto:anpa0508@telia.com]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by andreas <an...@telia.com>.
Indeed it does.
But I wonder what this means in terms of security?
I admit that my knowledge of the policy files and security-permissions is very weak, and granting permissions to something that I do not understand scares me a bit.
Maybe I should file a bug about this and let it get investigated by someone who knows.
Caldarale, Charles R wrote:
>
> I just verified that does correct the problem.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
> Subject: Re: Tomcat 6.0.20, JDK1.6.0_14 and security manager
>
> You may try adding
> permission java.lang.RuntimePermission "setContextClassLoader";
> for the "file:${catalina.home}/bin/tomcat-juli.jar"
I just verified that does correct the problem.
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6.0.20, JDK1.6.0_14 and security manager
Posted by Konstantin Kolinko <kn...@gmail.com>.
2009/6/6 andreas <an...@telia.com>:
> Hi!
>
> Have anyone beside me had any issues with the software versions mentioned in the subject line?
>
>
> First I thought it was my wacky setup, so I tried to "vanilla" directly from tomcat.apache.org, and it still fails.
>
> NOTE : Running the same tomcat installation with JDK1.6.0_12 produces no errors.
>
>
> This is what I get in 'catalina.out' with JDK1.6.0_14;
>
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied (java.lang.RuntimePermission setContextClassLoader)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at java.lang.Thread.setContextClassLoader(Thread.java:1351)
> at java.util.logging.LogManager$Cleaner.<init>(LogManager.java:204)
> at java.util.logging.LogManager$Cleaner.<init>(LogManager.java:198)
> at java.util.logging.LogManager.<init>(LogManager.java:235)
> at org.apache.juli.ClassLoaderLogManager.<init>(ClassLoaderLogManager.java:47)
> (..)
>
> Something happened in the latest JDK-release, question is what... :)
>
Do you have sources for JDK classes?
I do not have 6u14 installed yet - I have only 6u13, and the
LogManager.Cleaner class there has no explicit constructor and has no
Thread.setContextClassLoader() call.
I think that is what changed.
Without the sources I do not know why it calls it, and whether there
will be any problems due to that.
You may try adding
permission java.lang.RuntimePermission "setContextClassLoader";
for the "file:${catalina.home}/bin/tomcat-juli.jar"
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org