On 11/12/17 18:05, Christopher Schultz wrote: > Mark, > > On 12/11/17 12:47 PM, ma...@apache.org wrote: >> Author: markt >> Date: Mon Dec 11 17:47:03 2017 >> New Revision: 1817800 >> >> URL: http://svn.apache.org/viewvc?rev=1817800&view=rev >> Log: >> Pre-load additional classes to prevent SecurityExceptions if the first >> request received when running under a security manager is an asynchronous >> servlet. >> >> Modified: >> >> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java >> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml >> >> Modified: >> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java >> URL: >> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1817800&r1=1817799&r2=1817800&view=diff >> ============================================================================== >> --- >> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java >> (original) >> +++ >> tomcat/tc7.0.x/trunk/java/org/apache/catalina/security/SecurityClassLoad.java >> Mon Dec 11 17:47:03 2017 >> @@ -163,6 +163,10 @@ public final class SecurityClassLoad { >> private static final void loadCoyotePackage(ClassLoader loader) >> throws Exception { >> final String basePackage = "org.apache.coyote."; >> + // Classes created by the Java 6 compiler because we use switch >> with an enum >> + loader.loadClass(basePackage + "http11.Http11Processor$1"); >> + loader.loadClass(basePackage + "http11.Http11NioProcessor$1"); >> + loader.loadClass(basePackage + "http11.Http11AprProcessor$1"); > > I find it fragile to whitelist anonymous inner classes in this way. A > change to the target class (e.g. Http11Processor) could change the > meaning of the whitelist. > > Are there significant objections to making these into NAMED inner > classes? I believe it will be safer, and since this is intended to be a > SecurityManager-related whitelist, safer is better.
Given that these classes are auto-generated by the compiler, how do you propose to do that? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
