On Mon, 6 May 2002 [EMAIL PROTECTED] wrote:
> Date: Mon, 6 May 2002 11:16:24 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets
> ManagerServlet.java
>
> On 4 May 2002 [EMAIL PROTECTED] wrote:
>
> > Make the "/deploy" command recognize a "META-INF/context.xml" file embedded
> > inside the WAR, and process it as a context configuration file. This allows
> > deployment tool clients to customize the configuration of a webapp with
> > exactly the same degree of freedom as those that use the "/install" command,
> > with the added benefit of being able to deploy onto a Tomcat instance
> > running on a different server.
>
> This is a very dangerous path... Having server-config info in the webapp
> is extremely dangerous, it may (easily) break the sandbox.
>
> Unless there's something I'm missing, context.xml will allow loading of
> valves and other modules that have access to the server internal objects.
> This is a huge security hole.
>
Context XML files are like the app config files in 3.3 -- they can contain
any config parameters that could be found in server.xml inside a <Context>
element. However, any <Valve> implementation classes you try to specify
must exist in the server's classloader (i.e. in server/classes or
server/lib) already to actually take any effect. They will not be loaded
from the webapp's /WEB-INF directory.
It seems unlikely to me (in general) that untrusted users would have
any more access to the "webapps" directory than to the "conf" directory.
It seems even more unlikely to me that untrusted users would be allowed to
issue the Manager /deploy (or /install, which has the same level of
flexibility) commands, both of which are password protected.
> Well, having the config files in webapps/ is dangerous too - IMHO
> all potentially dangerous configs should be in conf/, since webapps
> may be writtable to more groups. But this is far worse.
>
> At least add a check to disable this if a security manager is present.
>
There's an existing "deployXML" property that can turn off context config
files -- I can extend it to cover the dynamic deployment cases as well.
>
> Costin
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
