On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
> 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. > Nowhere in any specification is this stated! Why can't a web application declare and provide a security manager? > > >> 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 > Thanks for your support. -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
