https://issues.apache.org/bugzilla/show_bug.cgi?id=55317
--- Comment #8 from Nick Williams <nicho...@nicholaswilliams.net> --- To address Jeremy's concerns/questions: 1) I don't see a security issue. JBoss, GlassFish, WebLogic, and WebSphere, for example, all "automatically enable this for all applications." You say, "Currently, that has to be specifically enabled by adding an agent to the JVM or by adding special classloader to the container installation and enabling it in a web application's Context," and I say that's a bad thing. It makes weaving difficult to configure, and sometimes impossible in hosted environments where the consumer doesn't have the ability to jump through these hoops. 2) I took some time to peruse the code on GlassFish, particularly org.glassfish.web.loader.WebappClassLoader. It performs no special security checks. If someone calls addTransformer, it just lets them add the transformer. That's all. It doesn't use a ProtectionDomain, and it passes null to the transformer's transform method. JBoss also performs no security checks in its code, though it does pass the existing ProtectionDomain to the transformer. It's up to the transformer to use or not use the ProtectionDomain, but apparently it's allowed to be null. 3) If a user enables cross-context dispatch (off by default), they don't do so accidentally (they may do so ignorantly, but that's not our concern). Enabling cross-context dispatch already has its own whole set of security concerns, and I consider the possibilities with this minor compared to those other security concerns. 4) I don't have any particular objection to some sort of Tomcat setting (maybe in catalina.properties?) that disables/disallows transformation, though I strongly believe it should be enabled by default. 5) "How does this interact with annotation scanning and ServletContainerInitializers?" All of this scanning happens /before/ any application code is allowed to execute. As such, it happens before any code is capable of adding transformers. Thus, this won't affect such scanning at all. Transformers are only going to want to instrument classes that they use--that won't be SCIs. As far as adding/removing annotations, the creator of a transformer to be used in a web application knows better than to attempt to add or remove annotations that might be scanned for by the container. None of the other containers do anything to anticipate/detect/prevent this bad programming practice, which wouldn't work but also wouldn't hurt anything. Now, to address what Rainer was saying about getThrowawayClassLoader(). After reading some GlassFish and JBoss source code, I've figured out what it's for. Code that adds transformers to a ClassLoader may need to initially load a class to determine whether it requires transformation (for example, Spring looks for classes annotated @Configurable and only adds a transformer for them if it finds a class annotated @Configurable). GlassFish implements this with a copy() method that simply returns a new UrlClassLoader with the same URL and parent class loader as the WebappClassLoader. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
