You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2002/11/25 14:07:24 UTC
catalina 2.0 still only SDK 1.4 ?
There is still in o.a.c.loader.WebappClassLoader :
/**
* Get URL.
*/
protected URL getURI(File file)
throws MalformedURLException {
File realFile = file;
try {
realFile = realFile.getCanonicalFile();
} catch (IOException e) {
// Ignore
}
return realFile.toURI().toURL();
}
Did someone has an idea to make this part of code JDK 1.2 compatible ?
--
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>
SSI Security Hack
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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: [5.0] Adding methods to Request
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Hi,
>>
>>In order to fix some GC problems in StandardPipeline and
>>StandardWrapper, where they allocate some context objects (for the
>>first, it means 3 objects / request, for the second, one complex object
>>/ request), I need to add methods to the Request interface:
>>- get/setFilterChain
>>- get/setValveContext
>>
>>This ties the contexts to the Request, which itself is thread safe, so
>>the objects can be reused. It will not break compatibility with any
>>existing module. This removes two hotspots, as well as improves GC :)
>>
>>When the security manager is enabled, the filter chain will not be
>>reused, to prevent possible exploits.
>>
>>IMO, this change should not be ported to the 4.1.x branch.
>>
>>Comments ?
>
>
> +1
>
> Maybe using something similar with the "Notes" would help ?
> The cost is very small ( array access versus field access ),
> and it can be used for anything.
>
> The current notes are recycled per request - that's why
> I said 'simiar', like 'permanentNotes".
Yes, this could be refactored later.
However, since we would want to keep compatibility with the old 4.x
modules (realms, valves, etc, etc), we are bound to have the Request
interface look bad (and some modules will bypass it to access the
optimized buffers instead of dealing with Strings).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Adding methods to Request
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Hi,
>
> In order to fix some GC problems in StandardPipeline and
> StandardWrapper, where they allocate some context objects (for the
> first, it means 3 objects / request, for the second, one complex object
> / request), I need to add methods to the Request interface:
> - get/setFilterChain
> - get/setValveContext
>
> This ties the contexts to the Request, which itself is thread safe, so
> the objects can be reused. It will not break compatibility with any
> existing module. This removes two hotspots, as well as improves GC :)
>
> When the security manager is enabled, the filter chain will not be
> reused, to prevent possible exploits.
>
> IMO, this change should not be ported to the 4.1.x branch.
>
> Comments ?
+1
Maybe using something similar with the "Notes" would help ?
The cost is very small ( array access versus field access ),
and it can be used for anything.
The current notes are recycled per request - that's why
I said 'simiar', like 'permanentNotes".
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[5.0] Adding methods to Request
Posted by Remy Maucherat <re...@apache.org>.
Hi,
In order to fix some GC problems in StandardPipeline and
StandardWrapper, where they allocate some context objects (for the
first, it means 3 objects / request, for the second, one complex object
/ request), I need to add methods to the Request interface:
- get/setFilterChain
- get/setValveContext
This ties the contexts to the Request, which itself is thread safe, so
the objects can be reused. It will not break compatibility with any
existing module. This removes two hotspots, as well as improves GC :)
When the security manager is enabled, the filter chain will not be
reused, to prevent possible exploits.
IMO, this change should not be ported to the 4.1.x branch.
Comments ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: catalina 2.0 still only SDK 1.4 ?
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> There is still in o.a.c.loader.WebappClassLoader :
>
> /**
> * Get URL.
> */
> protected URL getURI(File file)
> throws MalformedURLException {
>
> File realFile = file;
> try {
> realFile = realFile.getCanonicalFile();
> } catch (IOException e) {
> // Ignore
> }
> return realFile.toURI().toURL();
>
> }
>
> Did someone has an idea to make this part of code JDK 1.2 compatible ?
Yes, sorry about that, I'll do it soon.
You need to remove toURI() to fix the issue.
I'll rewrite the code using reflection (defaulting to realFile.toURL()
if there's a problem). Unfortunately, I see no way around :-(
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>