You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Dan Sandberg <x...@cs.stanford.edu> on 2002/11/25 21:01:52 UTC

SSI Security Hack

What's the story with the servlets-ssi.renametojar hack?

Are the classloader issues that necessitated this going to be fixed in 
Tomcat 5?  Will they be backported to Tomcat 4?

If this won't be fixed in Tomcat 5, than we can split servlets-ssi into 
the insecure part ( which can run exec ) and the secure part ( 
everything else ).  This would make using SSI much easier, as renaming 
jars and changing web.xml, etc, won't be necessary unless the user wants 
to support the #exec command.

[Just trying to keep an eye on end-user simplicity]

-Dan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SSI Security Hack

Posted by Pier Fumagalli <pi...@betaversion.org>.
On 25/11/02 20:01 "Dan Sandberg" <x...@cs.stanford.edu> wrote:

> What's the story with the servlets-ssi.renametojar hack?
> 
> Are the classloader issues that necessitated this going to be fixed in
> Tomcat 5?  Will they be backported to Tomcat 4?
> 
> If this won't be fixed in Tomcat 5, than we can split servlets-ssi into
> the insecure part ( which can run exec ) and the secure part (
> everything else ).  This would make using SSI much easier, as renaming
> jars and changing web.xml, etc, won't be necessary unless the user wants
> to support the #exec command.
> 
> [Just trying to keep an eye on end-user simplicity]

NO code is ever secure... Less stuff you distribute, fewer times Tomcat will
show up on BugTrack... That's my rule-of-the-thumb, at least...

IMO, even Jasper should be renamed to .renametojar, but that's just me,
probably being paranoid.

    Pier


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>