On Mon, 6 May 2002, Craig R. McClanahan wrote: > 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.
There's a lot that can be done only by using the internal classes to hook in some untrusted code. Messing with loggers for example would allow to override any file that tomcat core has access to. ( probably a bit hard to push content into it, but you get my point). The sandbox can protect you as long as you keep priviledged code separated. > 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. I think it is a typical use-case to delegate the admin of applications, while keeping the main server config under control. The webapp is designed to work in sandbox, with 'webapp deployer' role different from 'server admin' role. A large site may have hundreds of webapps, each with different 'managers' ( with web hosting beeing the extreme case ). Having conf/ writable by the 'server admin' group while webapp/ ( or each virtual host's webapp dir ) writable by the 'webapp deployer' group is usually a good idea ( and the main reason for using conf/apps- in 3.3, instead of webapps/apps-xml ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
