Re: Sources in Binary Distributions
As a tomcat user, I am not so enthousiast about your idea of removing the sources from the binaries. Almost every user download only the binaries. Having the sources inside means bringing more developers to the Tomcat project, just because it will be easier to take a look at the sources (since it is already installed in their tomcat dir). The more you look at the sources, the more you are likely to be involved. The sources are only about 2MB and 1 directory. It is anything but a mess on the harddisk. Furthermore it is the exact sources for the particular binary the user has, not some more recent or older sources. Regards, Fabien
Re: ApplicationContextFacade ClassCaseException
since tomcat 4.0 beta 5, ServletConfig is not a Wrapper anymore. To have access to the wrapper, you need your servlet to implement the ContainerServlet (or extend, not sure about this detail). Look at ManagerServlet for more information. regards, Fabien Amy Roh [EMAIL PROTECTED] writes: I'm getting this ServletException with the following message after new cvs checkout. The code was working fine before the cvs update. Anyone has an idea on what's been changed internally to cause this Exception? CGIServlet.java:355 contains these following lines. Wrapper wrapper = (Wrapper) getServletConfig(); context = (Context) wrapper.getParent(); Root Cause: java.lang.ClassCastException: org.apache.catalina.core.ApplicationContextFacade at org.apache.catalina.servlets.CGIServlet.init(CGIServlet.java:355) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:833) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:602) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:875) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952) at java.lang.Thread.run(Thread.java:484) Amy
container security issue
I apologize for repeating this, but I did not yet get any answer.
I wrote a servlet in a classic WAR file at an arbitrary location and NOT in the
org.apache.catalina package. From this servlet, I was able to access a method on the
Deployer, i.e. I was able to access anything public in any Container from outside.
This is only working by using reflection.
Here is the code (not clean, sorry about that) for the doGet method:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Conclusion: there is a security issue. We don't need the prerequisite to access
Catalina core classes. I am really wondering how it would be possible to fix this
security problem without an important redesign.
Regards,
Fabien
P.S.: should I include a WAR file?
Re: security and a servlet using core catalina classes
I am sorry, it seems I was not clear enough.
I wrote a servlet in a classic WAR file at an arbitrary location and NOT in the
org.apache.catalina package. The source code I copied in my last message was the
source code of the doGet() method for THIS servlet (outside the catalina package). And
it worked!
I was able to access a method on the Deployer, i.e. I was able to access anything
public in any Container from outside. This is only working by using reflection.
Conclusion: there is a security issue. We don't need the prerequisite to access
Catalina core classes.
Regards,
Fabien
Craig R. McClanahan [EMAIL PROTECTED] writes:
On 9 May 2001, Fabien Le Floc'h wrote:
Ok, this is possible to bypass the security!
Catalina conforms to the behavior in the Servlet 2.3 PFD2
Specification (Section 9.7.2) but does not comply with its
recommended behaviour.
Which recommended behavior are you concerned about? Catalina implements
both of them:
* not allow servlets in the WAR access to the web container's
implementation classes (which would be necessary to accomplish
what you are after here -- Catalina only lets servets installed in
$CATALINA_HOME/servlet have this kind of access).
* the application classloader be implemented so that classes and
resources packaged within the WAR are loaded in preference to
classes and resources residing in container-wide library JARs.
The fact that Catalina implements the second recommendation (which is
different behavior than Tomcat 3.2) means that you can have version X of
a particular package (say, a JDBC driver) available in the
$CATALINA_HOME/lib directory, but still be able to override it by placing
version Y of this driver, with the same package and class names, in your
WEB-INF/lib directory.
Here is the code (not clean, sorry about that) for the doGet method of an regular
servlet:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Yes, you will need access to Catalina internal structures to make this
work (via reflection or not does not matter). The prerequisites are:
* Your admin servlet must be in package org.apache.catalina (or a
subpackage of this package).
* Your admin servlet must be installed in $CATALINA_HOME/server/classes
or in a JAR file in $CATALINA_HOME/server/lib so that the Catalina
internal class loader can see it.
My project is to build a servlet inspector servlet for Tomcat in order
to have a Dynamo DCC like feature.
You might want to check out the Manager web app that is included already,
to see if it meets some or all of your needs. For example, to list the
webapps that are installed in a Tomcat 4.0 installation, simply execute:
http://localhost:8080/manager/list
To make this work, you must define a user (by default in the
$CATALINA_HOME/conf/tomcat-users.xml file) that has role manager,
because this web application is password protected by default. The
username and password assigned are arbitrary, as long as the authenticated
user is assigned the manager role.
The source code for this servlet
(org.apache.catalina.servlets.ManagerServlet) illustrates how
container-managed servlets can have direct access to Catalina internals
via casting (no reflection is required), because they are loaded by the
same class loader. As long as arbitrary users are prevented from
installing things under $CATALINA_HOME/server, the security of the
system itself is not compromised -- but you can easily create web
applications that have full access to internal server functionality.
(The invoker servlet that processes paths like /servlet/foo, and the
default servlet that serves static resources, are other examples of
container managed servlets that have access to internal Catalina classes
in exactly the same way.)
Regards,
Fabien
Craig
security and a servlet using core catalina classes
Thanks for your answer, I decided to put my servlet in the catalina hierarchy (on my personal computer). When it will be more advanced, I could even propose it as a contribution to catalina. But I think would have been possible to bypass the security by just using reflection to call the core methods. Regards, Fabien Glenn Nielsen [EMAIL PROTECTED] writes: In Tomcat 4 the core catalina classes in servlet/lib/catalina.jar are hidden from servlets. A servlet should use the standard Servlet 2.3 classes to access public information for the request. Your servlet would not be portable across differenct servlet containers if you used internal servlet container classes. In addition, making those interal tomcat classes visible to web applications could allow the security of the servlet container and web applications to be compromised. Regards, Glenn Fabien Le Floc'h wrote: Hello, I am sorry to bother you. But I am trying to write a servlet that uses some core apache classes and I have problems running it. - If I use a war archive, tomcat does not find the tomcat classes/servlet classes when it starts the servlet. (ClassNoDefFound error). If I then add the catalina.jar and servlet.jar to the classpath, I have a conflict between classes loaded dynamically by tomcat and classes in the classpath. (More precisely I have an object whose class is ServletWrapper but is not an instance of ServletWrapper. This is because (I guess) the object is created by the Tomcat classloader and it is compared with an instance of the classpath objects), - If I put the jar file in the common/lib directory, it finds the servlet classes but not the tomcat classes. - If I put the jar file in server/lib directory, it does not load my servlet. The only way I can make it work is to put it in the catalina.jar file. But that is not nice at all. Could someone help me with this? Thank you. Fabien Le Floc'h P.S.: I was wondering if it was user or developer oriented... As I want to use core Tomcat classes I thought it was developer but maybe I am wrong. Then I apologize. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
problems running a servlet that uses core catalina classes
Hello, I am sorry to bother you. But I am trying to write a servlet that uses some core apache classes and I have problems running it. - If I use a war archive, tomcat does not find the tomcat classes/servlet classes when it starts the servlet. (ClassNoDefFound error). If I then add the catalina.jar and servlet.jar to the classpath, I have a conflict between classes loaded dynamically by tomcat and classes in the classpath. (More precisely I have an object whose class is ServletWrapper but is not an instance of ServletWrapper. This is because (I guess) the object is created by the Tomcat classloader and it is compared with an instance of the classpath objects), - If I put the jar file in the common/lib directory, it finds the servlet classes but not the tomcat classes. - If I put the jar file in server/lib directory, it does not load my servlet. The only way I can make it work is to put it in the catalina.jar file. But that is not nice at all. Could someone help me with this? Thank you. Fabien Le Floc'h P.S.: I was wondering if it was user or developer oriented... As I want to use core Tomcat classes I thought it was developer but maybe I am wrong. Then I apologize.
