tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <jfarc...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
Date Wed, 22 Jan 2003 23:00:25 GMT


Hans Bergsten wrote:

> Jeanfrancois Arcand wrote:
>
>>
>>
>> Hans Bergsten wrote:
>>
>>> Jeanfrancois Arcand wrote:
>>>
>>>> [...]
>>>> We can support runtime package name addition (when the servlet is 
>>>> generated, ask the security manager to protect the package).  So it 
>>>> can be optional, i.e. being able to tell jasper to generate servlet 
>>>> using org.apache.jsp (something configurable via JMX ;-) ), without 
>>>> or with a aaa.bbb.ccc. Then when package generation option is 
>>>> selected, then ask the security manager to protect it.. It will be 
>>>> easy to document the functionality and that will  improve the 
>>>> security manager protection mechanim (by having the choice of 
>>>> protecting or not a package, and by having the choice of the 
>>>> package name).
>>>
>>>
>>>
>>>
>>> I admit I'm almost totally ignorant about this, so can you please
>>> explain why I would want to protect the package used for my JSP pages?
>>
>>
>>
>> In the normal case (when your web app is bundled as a standalone 
>> module), you doesn't need to protect your JSP. The classloader will 
>> protect your JSP. It is when you bundle more that one web app in a 
>> single war file that you may need protection.
>
>
> How can you bundle more that one app in a WAR file? A WAR file is the
> deployment format for _one_ web app only. 


True. It was more for one servlet trying to access another server. But 
that's not a valid case (let's call it a corner case)

>
>
>>> Who am I protecting myself against, what type of attack, in what type
>>> of environment? Given that each web app has it's own classloader and
>>> (I assume) is in control over what goes in it's web app structure, I
>>> just don't see the need for this protection. But I may be totally 
>>> wrong,
>>> so please enlighten me.
>>
>>
>>
>> You are right, but when the Tomcat classloading mechanism is not 
>> used, we need a way to still ensure the protection. That will not 
>> happen when you use Tomcat as it is, but that can happen in JBoss and 
>> J2EE RI (when you change the installation structure). 
>
>
> The servlet spec requires a separate classloader per web app, so I don't
> see how this could be a concern no matter which container is used.
>
>> And knowing how classloading works ;-)., I would prefer having a 
>> protection alternative.
>
>
> Sorry, but I strongly disagree. Adding security mechanisms for cases
> where it's not needed (assuming spec compliant implementations) only
> adds complexity to the code and have a negative impact on performance. 

We always check in the WebappLoader if a class has access to a required 
package before loading it. So the performance issue is already there 
(minus checking one package).

But your arguments are valid. So my security concern should not 
influence the decision of having a package or not for jsp. As I said in 
my first post, you can always manually add the security check in 
conf/tomcat.properties.

-- Jeanfrancois



>
>
> Hans



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


Mime
View raw message