RE: Sealing violation loading javax.security.auth.AuthPermission
Howdy, You probably have a mix of sealed and non-sealed jar in the same classloading repository. Where is the javax.security.auth package located? Yoav Shapira Millennium ChemInformatics -Original Message- From: Etienne Deleflie [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 1:46 AM To: [EMAIL PROTECTED] Subject: Sealing violation loading javax.security.auth.AuthPermission Hello all, I'm stumped! I'm getting a Sealing violation. and its got me beat. sealing violation trying to access javax.security.auth.AuthPermission . I cant find any reference to the same class in any other jar (eccept our own jars)... the problem does not exist on identical code that is not run with a servlet sandbox. java.lang.SecurityException: Sealing violation loading javax.security.auth.AuthPermission : Package javax.security.auth is sealed. at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappCl assL oader.java:1523) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoade r.ja va:852) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoade r.ja va:1273) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoade r.ja va:1156) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at com.company.software.userdatabase.UserManager.init(UserManager.java:1 10) etienne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sealing Violation due to inclusion of LifeCycle?
On Mon, 23 Dec 2002, Randy Secrist wrote: Date: Mon, 23 Dec 2002 11:25:51 -0700 From: Randy Secrist [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Sealing Violation due to inclusion of LifeCycle? I have been building classes inherited from the org.apache.catalina.realmbase package, and have been struggling with where to put them. One of the reason's I have been doing this is to expose TC's realm implementation within my web applications. The best solution I have found so far is to just drop the apache classes I need for my webapps into a .jar in the common/lib directory. I have been getting most of the functionality I want, but once I override the stop() method of RealmBase, I start getting a sealing violation due to the inclusion of LifeCycle, and LifeCycleException when tomcat starts up. I can see that once my hack gets deeper and deeper into TC code, I will windup with class loader issues, which I would like to avoid. Mostly, I am wondering (hoping) if there is a way to expose my custom user database (defined within GlobalNamingResource) within my webapps without having to worry so much about class loader issues, as I often find down in development that certian apache classes are not exposed within the class loader my web apps are using. I am hoping that the same class I can play with inside my applications, would be the same singleton instance that tomcat uses when it starts - but I haven't found an easy way to expose this. Does this violate some sort of MVC ideology? The fundamental documentation on how class loaders work in Tomcat is: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html If you look at the directory structure of a standard Tomcat distribution, you'll see that the org.apache.catalina.* classes (from catalina.jar) are loaded into the Catalina class loader, which is not visible to webapps. Therefore, any classes you write that need these APIs must also be stored in the Catalina class loader (putting them in the Common class loader won't help you, because they still wouldn't be able to see the base classes). The configuration option Tomcat supports for this is the privileged attribute on a Context element, which makes the the webapp's parent class loader be the Catalina loader instead of the Shared loader. This is the technique used by the admin and manager webapps that are shipped with Tomcat. WARNING: Use of this technique gives your webapp access to ***all*** of the internal objects of the servlet container, and is therefore very dangerous unless you are absolutely sure that your webapp cannot be abused by malicious users. Randy Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Sealing Violation due to inclusion of LifeCycle?
The fundamental documentation on how class loaders work in Tomcat is: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html If you look at the directory structure of a standard Tomcat distribution, you'll see that the org.apache.catalina.* classes (from catalina.jar) are loaded into the Catalina class loader, which is not visible to webapps. Therefore, any classes you write that need these APIs must also be stored in the Catalina class loader (putting them in the Common class loader won't help you, because they still wouldn't be able to see the base classes). The configuration option Tomcat supports for this is the privileged attribute on a Context element, which makes the the webapp's parent class loader be the Catalina loader instead of the Shared loader. This is the technique used by the admin and manager webapps that are shipped with Tomcat. WARNING: Use of this technique gives your webapp access to ***all*** of the internal objects of the servlet container, and is therefore very dangerous unless you are absolutely sure that your webapp cannot be abused by malicious users. Craig I didn't know about the privileged attribute at all. That could come in handy, but also dangerous. It appears (from the class loaders documentation) that objects from the shared class loader aren't available to the catalina loader as well, while objects created by the common loader are. When you make a context privileged, does that mean that it can still load a jar from the common loader, yet still have the visibility from the catalina, (instead of the external shared) loader? So basically if I make a context privileged, and still have objects in the shared loader, they won't be visible to the context. BUT - if I put everything in the common loader, and make the context privileged, I should be fine... - but possible open to security attacks depending on what I put in there? BTW - I want to thank you for doing this Craig. I have enjoyed using Tomcat and Struts for MVC models while studying at my local university... Randy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Sealing Violation due to inclusion of LifeCycle?
On Mon, 23 Dec 2002, Tomcat User wrote: Date: Mon, 23 Dec 2002 13:11:05 -0700 From: Tomcat User [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Sealing Violation due to inclusion of LifeCycle? The fundamental documentation on how class loaders work in Tomcat is: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html If you look at the directory structure of a standard Tomcat distribution, you'll see that the org.apache.catalina.* classes (from catalina.jar) are loaded into the Catalina class loader, which is not visible to webapps. Therefore, any classes you write that need these APIs must also be stored in the Catalina class loader (putting them in the Common class loader won't help you, because they still wouldn't be able to see the base classes). The configuration option Tomcat supports for this is the privileged attribute on a Context element, which makes the the webapp's parent class loader be the Catalina loader instead of the Shared loader. This is the technique used by the admin and manager webapps that are shipped with Tomcat. WARNING: Use of this technique gives your webapp access to ***all*** of the internal objects of the servlet container, and is therefore very dangerous unless you are absolutely sure that your webapp cannot be abused by malicious users. Craig I didn't know about the privileged attribute at all. That could come in handy, but also dangerous. It appears (from the class loaders documentation) that objects from the shared class loader aren't available to the catalina loader as well, while objects created by the common loader are. When you make a context privileged, does that mean that it can still load a jar from the common loader, yet still have the visibility from the catalina, (instead of the external shared) loader? Yes, classes loaded from the Common class loader can still be loaded from a privileged webapp. However, a class loaded from the Common class loader cannot depend on a class loaded from the Catalina class loader -- for example, you cannot put a subclass of org.apache.catalina.realm.RealmBase in the common class loader. That's because Java does not support links from a ClassLoader to its children -- only to its parent. So basically if I make a context privileged, and still have objects in the shared loader, they won't be visible to the context. BUT - if I put everything in the common loader, and make the context privileged, I should be fine... Almost ... see the issue raised above. - but possible open to security attacks depending on what I put in there? It's definitely possible to have security attacks. What that should do is cause you to re-examine whether your webapp itself really needs to update the internal object instances, or just the underlying data. For example, if JDBCRealm was sufficient to meet your needs but you wanted to support dynamically adding new users, it would be straightforward to simply write a non-privileged webapp that updated the same tables you told JDBCRealm to use -- any new user that is added that way becomes immediately allowed to log on. It's not clear from your problem description why you needed to extend RealmBase in the first place, but it is worth considering whether a strategy like this would help you. BTW - I want to thank you for doing this Craig. I have enjoyed using Tomcat and Struts for MVC models while studying at my local university... Randy Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: sealing violation
From what I have read on the list, this error is normally (99%) related to having mixed versions of the servlet jar's in your class path. Make sure that you are not sharing the servlet.jar from a previous version of the spec with the one distributed with tomcat. -Original Message- From: Boszormenyi GCS Laszlo [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 23, 2001 5:44 AM To: [EMAIL PROTECTED] Subject: sealing violation Hello, I am trying to deploy Tomcat 4.0b3 with Java 1.3. When I do startup.sh, I get: ERROR reading /usr/local/conf/server.xml At Line 75 /Server/Service/Engine/ name=Standalone defaultHost=localhost debug=0 Catalina.start: java.lang.SecurityException: sealing violation java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) Searching the mail archive gave me a point, my jar files are symbolic links to the real ones. Also, they contains /../, which seems to be the problem(?). I have a very good reason to do it, so what I would like to do, is turn off this security feature. Can you please tell me how to do this? Thanks, Laszlo
Re: sealing violation
* CPC Livelink Admin [EMAIL PROTECTED] [010423 16:11]: From what I have read on the list, this error is normally (99%) related to having mixed versions of the servlet jar's in your class path. Make sure that you are not sharing the servlet.jar from a previous version of the spec with the one distributed with tomcat. The machine is just installed, so it is sure that there were not even a jdk. I was playing with the paths, and finaly I unset all of them. Then tried startup.sh again. It complained about JAVA_HOME and CATALINA_HOME. I set up to the real files, without symlinks: export JAVA_HOME=/usr/local/encap/jdk1.3.0_02 export CATALINA_HOME=/usr/local/encap/jakarta-tomcat-4.0b3 startup.sh gave me sealing violation again. The $CLASSPATH was empty for sure, I modified the startup.sh to do an echo on it, and I saw an empty line only this time. Anyway, Catalina/Tomcat reports: Using CLASSPATH: /usr/local/encap/jakarta-tomcat-4.0b3/bin/bootstrap.jar:/usr/local/encap/jdk1.3.0_02/lib/tools.jar Using CATALINA_HOME: /usr/local/encap/jakarta-tomcat-4.0b3 Is it ok? Anyway, I am going to throw in the towel... Absolutely no more idea. Bye, Laszlo
RE: sealing violation in 4.0m5
Hi Bill. I believe a "sealing violation" is when a class which was loaded under one classloader tries to call a class loaded under a different classloader, in circumstances where this isn't allowed. I suggest that the problem is therefore something to do with classpaths, ie your classpath includes some files it shouldn't. The result is that tomcat is expecting code to be loaded by a particular classloader, but because it is in the classpath, it has already been loaded by the system class loader. Hope this helps, Simon -Original Message- From: Bill Pfeiffer [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 20, 2000 6:06 AM To: Tomcat Subject: sealing violation in 4.0m5 Trying to port my 3.2 app to 4.0. One simple page works, but the main page of my app yeilds the exception below. Any idea what a "sealing violation' is? Sounds like a security issue. Ideas? TIA, Bill Pfeiffer A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.init() for servlet OasisCommand threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:774) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.jav a: 811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:89 0) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoad er .java:648) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:987) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:906) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at com.pdma.oasis.servlets.OasisCommandServlet.initCommands(OasisCommandServl et .java:94) at com.pdma.oasis.servlets.OasisCommandServlet.init(OasisCommandServlet.java: 27 ) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:755) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.jav a: 811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:89 0) at java.lang.Thread.run(Thread.java:484)
Re: sealing violation in 4.0m5
Classpath is not set (ie set to empty) when starting Tomcat. My web app does include some jars, none of which should clash with Tomcat. Any other ideas on what to start looking for in terms of a clash?. The class in question appears to be one of my own in the WEB-INF/class directory. Thanks, Bill Pfeiffer - Original Message - From: "Kitching Simon" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 20, 2000 6:06 AM Subject: RE: sealing violation in 4.0m5 Hi Bill. I believe a "sealing violation" is when a class which was loaded under one classloader tries to call a class loaded under a different classloader, in circumstances where this isn't allowed. I suggest that the problem is therefore something to do with classpaths, ie your classpath includes some files it shouldn't. The result is that tomcat is expecting code to be loaded by a particular classloader, but because it is in the classpath, it has already been loaded by the system class loader. Hope this helps, Simon -Original Message- From: Bill Pfeiffer [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 20, 2000 6:06 AM To: Tomcat Subject: sealing violation in 4.0m5 Trying to port my 3.2 app to 4.0. One simple page works, but the main page of my app yeilds the exception below. Any idea what a "sealing violation' is? Sounds like a security issue. Ideas? TIA, Bill Pfeiffer A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.init() for servlet OasisCommand threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:774) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.jav a: 811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:89 0) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoad er .java:648) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:987) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:906) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at com.pdma.oasis.servlets.OasisCommandServlet.initCommands(OasisCommandServl et .java:94) at com.pdma.oasis.servlets.OasisCommandServlet.init(OasisCommandServlet.java: 27 ) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:755) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invo
Re: sealing violation in 4.0m5
Bill Pfeiffer wrote: Classpath is not set (ie set to empty) when starting Tomcat. With Tomcat 4.0 using standard startup scripts, this does not matter -- the user's CLASSPATH variable is totally ignored. My web app does include some jars, none of which should clash with Tomcat. My understanding is that a "sealing violation" is not caused by a conflict with Tomcat -- rather, it's caused when you try to load a class A in a particular package from one JAR, and class B from the same package from another JAR. I do not believe it matters whether it's the same class loader or not; the issue is that a sealed package should be completely loaded from a single JAR. But I'm not done doing my own research to understand this problem, either. Any other ideas on what to start looking for in terms of a clash?. The class in question appears to be one of my own in the WEB-INF/class directory. Do you by chance have some un-JAR'd classes under WEB-INF/classes, and some other classes in the same package found in a JAR file? Thanks, Bill Pfeiffer Craig McClanahan
