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]>
