There is one issue with the code in http://goo.gl/zASBm, though: It checks for getClassLoader permission in a static code block only, i.e. when the class is initially loaded by the classloader, and saves that information for later reference.
I don't think that this is a valid optimization for precisely the reason that this permission can change during runtime (according to http://download.oracle.com/javase/1.4.2/docs/api/java/security/AccessController.html even per thread), for example if a different SecurityManager is installed. The method using the statically initialized boolean should probably look like this instead: public static ClassLoader getClassLoaderAsPrivileged(final Class clazz) { try { AccessController.checkPermission(new RuntimePermission("getClassLoader")); return AccessController.doPrivileged( new PrivilegedAction<ClassLoader>() { public ClassLoader run() { return clazz.getClassLoader(); } }); } catch (AccessControlException e) { return null; } } Not sure if this would solve the problem at hand... Joern. On 05.11.2011, at 16:25, ceki wrote: > > Thanks for the sample project. I can confirm that I observe a > AccessControlException when logback is present. The > AccessControlException is not thrown if slf4j-nop, slf4j-simple or > slf4j-log4j are used as the slf4j binding. > > Although logback does not install its own SecurityManager or modify > the security configuration, it does attempt to determine whether it > has "getClassLoader" permission. See http://goo.gl/zASBm > > Here is the code in question: > > AccessController.doPrivileged(new PrivilegedAction<Boolean>() { > public Boolean run() { > try { > AccessController.checkPermission( > new RuntimePermission("getClassLoader")); > return true; > } catch (AccessControlException e) { > return false; > } > } > }); > > > If the privileged block above code is removed, then the > AccessControlException goes away. The privileged block looks quite > legitimate to me so I don't think it's a bug in logback. > > To convince yourself the the privileged block is key, you can remove > all logging related calls and all logging related dependencies, add > the privileged block at the beginning of the test. You should observe > an AccessControlException being thrown. > > -- > Ceki > http://twitter.com/#!/ceki > > > > On 11/5/2011 1:42 PM, Andrew Bourgeois wrote: >> Ceki, >> >> I redid the test in a clean Maven project. I don't know if attachments >> will pass through, so: >> >> 1) pom.xml: >> >> <project xmlns="http://maven.apache.org/POM/4.0.0"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> http://maven.apache.org/maven-v4_0_0.xsd";> >> <modelVersion>4.0.0</modelVersion> >> <name>test</name> >> <groupId>be.test.fun</groupId> >> <artifactId>test</artifactId> >> <version>0.1.0-RC1</version> >> <dependencies> >> <dependency> >> <groupId>org.slf4j</groupId> >> <artifactId>slf4j-api</artifactId> >> <version>1.6.0</version> >> </dependency> >> >> <dependency> >> <groupId>log4j</groupId> >> <artifactId>log4j</artifactId> >> <version>1.2.16</version> >> </dependency> >> <dependency> >> <groupId>org.slf4j</groupId> >> <artifactId>slf4j-log4j12</artifactId> >> <version>1.6.0</version> >> </dependency> >> >> <!--dependency> >> <groupId>ch.qos.logback</groupId> >> <artifactId>logback-core</artifactId> >> <version>1.0.0</version> >> </dependency> >> <dependency> >> <groupId>ch.qos.logback</groupId> >> <artifactId>logback-classic</artifactId> >> <version>1.0.0</version> >> </dependency--> >> >> <dependency> >> <groupId>junit</groupId> >> <artifactId>junit</artifactId> >> <version>4.4</version> >> <scope>test</scope> >> </dependency> >> </dependencies> >> <build> >> <resources> >> </resources> >> <plugins> >> <plugin> >> <artifactId>maven-compiler-plugin</artifactId> >> <configuration> >> <source>1.6</source> >> <target>1.6</target> >> <verbose>true</verbose> >> </configuration> >> </plugin> >> </plugins> >> </build> >> </project> >> >> 2) The JUnit test: >> >> package be.test.fun; >> >> import org.junit.Test; >> import java.rmi.RMISecurityManager; >> import org.slf4j.Logger; >> import org.slf4j.LoggerFactory; >> >> public class SecurityManagerTest { >> >> @Test >> public void securityManagerWithLogs() { >> Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); >> >> System.setProperty("java.security.policy", >> "./src/test/resources/java.policy"); >> logger.debug("Policy location: {}", >> System.getProperty("java.security.policy")); >> if (System.getSecurityManager() == null) { >> System.setSecurityManager(new RMISecurityManager()); >> } >> System.setProperty("java.security.policy", >> "./src/test/resources/java.policy"); >> } >> >> // @Test >> // public void securityManagerWithoutLogs() { >> // System.setProperty("java.security.policy", >> "./src/test/resources/java.policy"); >> // if (System.getSecurityManager() == null) { >> // System.setSecurityManager(new RMISecurityManager()); >> // } >> // System.setProperty("java.security.policy", >> "./src/test/resources/java.policy"); >> // } >> } >> >> 3) java.policy that you put into src/test.resources: >> >> grant { >> permission java.security.AllPermission; >> }; >> >> So.... if you run this: >> ------------------------------------------------------- >> T E S T S >> ------------------------------------------------------- >> Running be.test.fun.SecurityManagerTest >> 2011-11-05 13:36:33,828 [main] DEBUG - (be.test.fun.SecurityManagerTest) >> - Policy location: ./src/test/resources/java.policy >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.201 sec >> >> Results : >> >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 >> >> Now, comment the 2 LOG4J-related dependencies inside the POM, and >> uncomment the logback ones: >> ------------------------------------------------------- >> T E S T S >> ------------------------------------------------------- >> Running be.test.fun.SecurityManagerTest >> 13:38:04.222 [main] DEBUG be.test.fun.SecurityManagerTest - Policy >> location: ./src/test/resources/java.policy >> java.security.AccessControlException: access denied >> (java.lang.RuntimePermission setContextClassLoader) >> at >> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) >> >> at >> java.security.AccessController.checkPermission(AccessController.java:546) >> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) >> at java.lang.Thread.setContextClassLoader(Thread.java:1394) >> at >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:366) >> >> at >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 2.202s >> >> And now comment the "securityManagerWithLogs" test method, and uncomment >> the "securityManagerWithoutLogs" one: >> ------------------------------------------------------- >> T E S T S >> ------------------------------------------------------- >> Running be.test.fun.SecurityManagerTest >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.105 sec >> >> Results : >> >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 >> >> Do you have the same output? >> >> FYI: >> >> [xvepak@localhost test]$ mvn -version >> Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) >> Java version: 1.6.0_23 >> Java home: /home/xvepak/software/jdk1.6.0_23/jre >> Default locale: en_US, platform encoding: UTF-8 >> OS name: "linux" version: "2.6.18-238.12.1.el5" arch: "i386" Family: "unix" >> >> Thank you for trying to help out!! >> >> Best regards >> >> Andrew Bourgeois >> >> -----Original Message----- From: ceki >> Sent: Saturday, November 05, 2011 1:03 AM >> To: logback users list >> Subject: Re: [logback-user] SecurityManager issue using logback >> >> On 05/11/2011 12:47 PM, Andrew Bourgeois wrote: >> >>> So to reformulate: >>> The exception IS thrown when we have SLF4J code >>> The exception ISN'T thrown when we remove the SLF4J. >> >> That's not what I observe. An exception is thrown in both cases. > > > > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
