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)
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).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.
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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
