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; i<apps.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
