What I find interesting is that IntelliJ says getClassLoaderAsPrivileged isn't even used by anything in Logback.
Ralph On Nov 5, 2011, at 5:32 PM, Joern Huxhorn wrote: > 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 _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
