Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Date: Wed, 9 May 2001 20:32:32 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: tomcat-dev@jakarta.apache.org
Subject: Re: security and a servlet using core catalina classes
In-Reply-To: <m2heyt7wil.fsf@peanut.one0.com>
Message-ID: <Pine.BSF.4.21.0105092016300.96731-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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