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>