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 17:05:01 GMT
Jean-Francois Arcand wrote:
> OK, let's try to describe the problem. First, here is the stack trace 
> the application is throwing when running:
> 
> java.lang.NullPointerException
>     at 
> org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca 
> 
> de.java:271)
>     at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306)
>     at 
> com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284)
>     at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204)
>     at 
> com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236)
>     at 
> com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178)
>     at 
> org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205)
>     at 
> org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138)
>     at 
> org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97 
> 
> )
>     at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70)
>     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 
> I don't think this is an application bug.
> 
> 
> Note that the problem doesn't occurs with 4.0.x or if you run it without 
>   the security manager. The first time the application runs (very simple 
> test), no exception is produced. The second time you run, then the old 
> facade object (the one used by the first request) is still available but 
> since the clear method has been invoked, the request instance is set to 
> null (so the NPE is thrown). It is clear that the facade object used 
> when the NPE is thrown is the one used by the first invokation. It seems 
> that facade object has not been recycled properly.
> 
> I can send you the war file if you want to see the behaviour. It is very 
> easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with 
> package protection/access and the security changes we made in 5).
> 
> I don't think the current solution open security issue, but I agree it 
> is not an elegant solution. The other solution we have is to not invoke, 
> in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to 
> null the CoyoteRequest. That solution works also:
> 
> Index: CoyoteRequest.java
> ===================================================================
> RCS file: 
> /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v

> 
> retrieving revision 1.8
> diff -u -r1.8 CoyoteRequest.java
> --- CoyoteRequest.java  6 Jun 2003 03:03:33 -0000       1.8
> +++ CoyoteRequest.java  6 Jun 2003 16:55:13 -0000
> @@ -438,7 +438,6 @@
>          mappingData.recycle();
> 
>          if ((Constants.SECURITY) && (facade != null)) {
> -            facade.clear();
>              facade = null;
>          }
> .
> This way the facade will be cleared and we will not create a facade for 
> every request.

If a webapp hags on to the facade, it can access the underlying request. 
That seems to me like a security problem. That also seems like a 
security bug to Bill, and that's why we both vetoed your commit.

I will look at the bug. However, since the facade is only cleared at the 
end of the request processing (in the recycle), I don't see how you can 
produce a valid test case.
It could be a bug with the tag and tag pooling. Disable tag pooling to 
see if it fixes the problem.

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