You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Randy Secrist <to...@secristfamily.com> on 2002/12/23 19:25:51 UTC
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?
Randy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sealing Violation due to inclusion of LifeCycle?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 23 Dec 2002, Tomcat User wrote:
> Date: Mon, 23 Dec 2002 13:11:05 -0700
> From: Tomcat User <to...@secristfamily.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sealing Violation due to inclusion of LifeCycle?
Posted by Tomcat User <to...@secristfamily.com>.
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sealing Violation due to inclusion of LifeCycle?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 23 Dec 2002, Randy Secrist wrote:
> Date: Mon, 23 Dec 2002 11:25:51 -0700
> From: Randy Secrist <to...@secristfamily.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>