tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <>
Date Sun, 18 Aug 2013 16:15:17 GMT
Hello everyone,

My name is Raymond Auge and this is my first message to the list. Hopefully
I follow protocol correctly. Let me know if I don't.



is a global (static final) constant. As such it is evaluated exactly once.

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.

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.

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());

4) from that point, all Jasper code will provide the incorrect state, app
server wide

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.

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?

*Raymond Augé* <>
Senior Software Architect
*Liferay, Inc.* <> (@Liferay)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message