Ceki, actually, a third option is not to use System.setProperty(...) for java.security.policy, but pass it as a parameter when launching the app (-Djava.security.policy=java.policy). FYI: I only use System.setProperty(...) for small systests that I launch from my IDE. Best regards Andrew Bourgeois -----Original Message----- From: Andrew Bourgeois Sent: Saturday, November 05, 2011 5:28 PM To: logback users list Subject: Re: [logback-user] SecurityManager issue using logback Ceki, you're right, I do get the exception when executing that block of code. I have 2 workarounds for my problem: 1) Put the java.policy file into $JAVA_HOME/jre/lib/security: That's too dirty, I'll skip this one. 2) Initialize the security manager before initializing logback: @Test public void loggingAfterSecurityManager() { System.setProperty("java.security.policy", "./src/test/resources/java.policy"); if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); logger.debug("Policy location: {}", System.getProperty("java.security.policy")); System.setProperty("java.security.policy", "./src/test/resources/java.policy"); } The test passes because I did what I had to do before loading the logback classes. The following doesn't pass: @Test public void loggingBeforeSecurityManager() { Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); logger.debug("Policy location: {}", System.getProperty("java.security.policy")); System.setProperty("java.security.policy", "./src/test/resources/java.policy"); if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } logger.debug("Policy location: {}", System.getProperty("java.security.policy")); } If I dare to initialize logback before initializing a security manager, once I do it, it all goes wrong with code that uses the SecurityManager (so the last logger.debug(...) fails!). I'm not an expert so I can't say it's bad, but it's annoying. Thank you for your help! Best regards Andrew Bourgeois -----Original Message----- From: ceki Sent: Saturday, November 05, 2011 4:25 PM To: logback users list Subject: Re: [logback-user] SecurityManager issue using logback 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