tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
Date Fri, 06 Jun 2003 06:44:19 GMT
jfarcand@apache.org wrote:
> jfarcand    2003/06/05 20:03:33
> 
>   Modified:    catalina/src/share/org/apache/coyote/tomcat5
>                         CoyoteRequest.java
>   Log:
>   When the SecurityManager is turned on, the facade is never properly garbaged. Bugtraq
48
>   66915 demonstrates a case where CoyoteRequestFacade is re-used with a request object
equ
>   als to null (the getAttribute throws NPE). The bug also exists in Tomcat 4.1.x. (should
>   I port the patch?)
>   
>   Also, the way response are recycled may also produce the same behaviour, althrough
I can
>   't reproduce the exception.

Ok, I thought about it a bit more.

To give you more detail, the code in recycle() is:

         if ((Constants.SECURITY) && (facade != null)) {
             facade.clear();
             facade = null;
         }

Doing a clear forces the facade to dump its pointer to the request, so 
you can't hold to the reference and invoke methods on it (you get NPEs). 
What you did leads possibly to the creation of multiple facades, and 
only the last one will be cleared. All others will still have a pointer 
to the real request object, so could be used by a rogue thread to access 
data randomly. As I don't quite remember if the last facade would be 
given to the webapp (it could well be), your patch opens a potential 
secuity problem.
To summarize, there's no point in facading for security (the security 
manager will already protect from casting and method invocation) unless 
you guarantee that all facades are disassociated from the underlying 
request object.

So, I'm confirming my -1 for the patch.

Maybe you could post details on the bugs you're trying to fix. If it's 
valid (I doubt it, all the similar NPEs I've seen were invalid), then 
we'll need to find a safe solution.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message