On 18/08/2013 17:34, Raymond Auge wrote: > I've filed a bugs: > > https://java.net/jira/browse/JSP-37 > https://issues.apache.org/bugzilla/show_bug.cgi?id=55446
And I have closed the Tomcat one as invalid. > On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge > <raymond.a...@liferay.com>wrote: >> Since Jasper is typically provided as part of the app server this means >> it's impossible for some later module to enable Java security dynamically. Correct. This is by design. >> The Java security API is clearly dynamic. It allows for the creation of >> both security managers and policies created and registered at runtime. >> >> The JVM itself always performs dynamic evaluation of security (normally >> the very same null check which is stored by IS_SECURITY_ENABLED. Irrelevant. >> Scenario demonstrating a problem: >> >> 1) start tomcat normally (no security) >> 2) assuming any normal app is initialized, a JspRuntimeContext will be >> created and at first invocation >> >> Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null); >> >> is evaluated. >> >> 3) deploy some later component (ie. a webapp) which does: >> >> System.setSecurityManager(new SecurityManager()); Web applications have no business trying to configure a security manager. First of all this is a container concern, not an application concern. Secondly, a security manager applies JVM wide. An application has no way to determine how to configure a security manager to enable any other applications to operate correctly. This is why it is a container concern where the deployer can determine a) if they require a security manager in their environment (something else an application has no way of determining) and b) what an appropriate security policy is for their environment. >> I realize this is a very long standing mechanism. I'm wondering what would >> be the odds of accepting a patch which enables a dynamic check as opposed >> to global constant. Zero. I would veto any commit that applied such a patch. >> A further change would be required to initialize security dynamically >> which I think could be done simply enough without incurring significant >> performance issue. >> >> BTW, this issue affects every app server which uses Jasper (including >> users of the JSR RI in the Glassfish project) >> >> Any thoughts? You haven't thought through the implications of your proposal nor the practicalities of how it would work. The point being that it couldn't work. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
