Hi there, I've just run into a problem with using logback in a jvm where the security manager is enabled. The trace of the exception is as follows: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) 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.Class.getClassLoader(Class.java:594) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:87) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:425) at ch.qos.logback.classic.Logger.info(Logger.java:645) This is running with a logback-classic-0.9.23-SNAPSHOT that I pulled and built a couple of days ago. Looking at the code it seems the PackagingDataCalculator should be calling getClassLoader in an AccessController.doPriviledged block - but potentially this could also happen higher up to avoid having to put micro checks in all over the place. This leads me to a couple of questions: * Is logback generally dealing with security related checks and this is just one that's slipped through? * From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously? Thanks in advance, Regards, Dave
On Wed, 07 Jul 2010 15:41:43 +0100, David Savage wrote:
* From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously?
I have no idea what any of this means but I think you meant "lazily", as in "on demand" - right? async stack trace filling sounds .. complicated. :) Holger
On 7 Jul 2010, at 17:42, "Holger Hoffstaette" <holger.hoffstaette@googlemail.com> wrote:
On Wed, 07 Jul 2010 15:41:43 +0100, David Savage wrote:
* From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously?
I have no idea what any of this means but I think you meant "lazily", as in "on demand" - right? async stack trace filling sounds .. complicated. :)
Yep sorry that's what I meant :) Regards Dave
Holger
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
On 07/07/2010 4:41 PM, David Savage wrote:
Hi there,
I've just run into a problem with using logback in a jvm where the security manager is enabled. The trace of the exception is as follows:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) 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.Class.getClassLoader(Class.java:594) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:87) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:425) at ch.qos.logback.classic.Logger.info(Logger.java:645)
This is running with a logback-classic-0.9.23-SNAPSHOT that I pulled and built a couple of days ago.
Looking at the code it seems the PackagingDataCalculator should be calling getClassLoader in an AccessController.doPriviledged block - but potentially this could also happen higher up to avoid having to put micro checks in all over the place.
This leads me to a couple of questions:
* Is logback generally dealing with security related checks and this is just one that's slipped through?
No, logback does not do security checks.
* From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously?
That work only done after an exception is thrown which is by definition exceptional, so performance should not be a real problem.
Thanks in advance,
Regards,
Dave
On Wed, Jul 7, 2010 at 8:16 PM, Ceki Gülcü <ceki@qos.ch> wrote:
On 07/07/2010 4:41 PM, David Savage wrote:
Hi there,
I've just run into a problem with using logback in a jvm where the security manager is enabled. The trace of the exception is as follows:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) 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.Class.getClassLoader(Class.java:594) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:87) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:425) at ch.qos.logback.classic.Logger.info(Logger.java:645)
This is running with a logback-classic-0.9.23-SNAPSHOT that I pulled and built a couple of days ago.
Looking at the code it seems the PackagingDataCalculator should be calling getClassLoader in an AccessController.doPriviledged block - but potentially this could also happen higher up to avoid having to put micro checks in all over the place.
This leads me to a couple of questions:
* Is logback generally dealing with security related checks and this is just one that's slipped through?
No, logback does not do security checks.
Ok that's understandable but a little bit of a problem for our usecase. I'll see if we have any bandwidth to work on it but in principle if we were to make updates to do the various AccessControl checks would you be interested in contributions to make this work?
* From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously?
That work only done after an exception is thrown which is by definition exceptional, so performance should not be a real problem.
Hmmm yep on reflection that makes sense. Regards, Dave
Thanks in advance,
Regards,
Dave
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
On 07/07/2010 9:36 PM, David Savage wrote:
On Wed, Jul 7, 2010 at 8:16 PM, Ceki Gülcü<ceki@qos.ch> wrote:
On 07/07/2010 4:41 PM, David Savage wrote:
Hi there,
I've just run into a problem with using logback in a jvm where the security manager is enabled. The trace of the exception is as follows:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) 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.Class.getClassLoader(Class.java:594) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:87) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:425) at ch.qos.logback.classic.Logger.info(Logger.java:645)
This is running with a logback-classic-0.9.23-SNAPSHOT that I pulled and built a couple of days ago.
Looking at the code it seems the PackagingDataCalculator should be calling getClassLoader in an AccessController.doPriviledged block - but potentially this could also happen higher up to avoid having to put micro checks in all over the place.
This leads me to a couple of questions:
* Is logback generally dealing with security related checks and this is just one that's slipped through?
No, logback does not do security checks.
Ok that's understandable but a little bit of a problem for our usecase. I'll see if we have any bandwidth to work on it but in principle if we were to make updates to do the various AccessControl checks would you be interested in contributions to make this work?
Logback professional support covers such work. Contact me off list for details. -- Ceki
participants (3)
-
Ceki Gülcü -
David Savage -
Holger Hoffstaette