java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read")

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • If Java-Security is enabled and the log message that triggers the file rolling (e.g. because the file size limit has been reached) has been written by code from an untrusted domain, an {{AccessControlException}} is thrown if the callers domain does not have the necessary privileges to rollover the logfile (read, write). That's because *every* domain in the call stack must have the required privileges. Example: * Security is enabled. * A log message is written (or an {{ILoggingEvent}} is fired) by unstrusted code. * *This* (!) event causes the file rollover. * {{SecurityException}} is thrown, because the logger call is in the rollover call stack. {code:title=Excerpt from StatusPrinter} ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FOO] - Appender [FOO] failed to append. java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read") at java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read") at at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.internalCheckPermission(EquinoxSecurityManager.java:117) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager$CheckPermissionAction.run(EquinoxSecurityManager.java:60) at at java.security.AccessController.doPrivileged(Native Method) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:88) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:186) at at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at at java.io.File.length(File.java:910) at at ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy.isTriggeringEvent(SizeBasedTriggeringPolicy.java:59) at at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:170) at at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:441) at at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:413) at at ch.qos.logback.classic.Logger.info(Logger.java:603) at at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at at java.lang.reflect.Method.invoke(Method.java:601) at at org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:425) at at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:292) ... {code} (i) In this example the untrusted code domain is {{JRuby}}, which has evaluated a script that wrote a log message. This issue can be solved by marking the rollover call from within the LOGBack domain as _privileged_ using {{AccessController.doPrivileged()}}. As the rollover is actually triggered in {{RollingFileAppender#subAppend(E event)}} this should be straightforward. Instead of {code:lang=java} if (triggeringPolicy.isTriggeringEvent(currentlyActiveFile, event)) { rollover(); } {code} we could use {code:lang=java} AccessController.doPrivileged(new PrivilegedAction<Void>() { @Override public Void run() { if (triggeringPolicy.isTriggeringEvent(currentlyActiveFile, event)) { rollover(); } return null; } }); {code} to mark both the file read access in {{triggeringPolicy.isTriggeringEvent()}} as well as the write access in {{rollover()}} as _privileged_. (/) I will provide a simple pull request to fix this issue.
    via by Christian Brensing,
  • If Java-Security is enabled and the log message that triggers the file rolling (e.g. because the file size limit has been reached) has been written by code from an untrusted domain, an {{AccessControlException}} is thrown if the callers domain does not have the necessary privileges to rollover the logfile (read, write). That's because *every* domain in the call stack must have the required privileges. Example: * Security is enabled. * A log message is written (or an {{ILoggingEvent}} is fired) by unstrusted code. * *This* (!) event causes the file rollover. * {{SecurityException}} is thrown, because the logger call is in the rollover call stack. {code:title=Excerpt from StatusPrinter} ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FOO] - Appender [FOO] failed to append. java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read") at java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read") at at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.internalCheckPermission(EquinoxSecurityManager.java:117) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager$CheckPermissionAction.run(EquinoxSecurityManager.java:60) at at java.security.AccessController.doPrivileged(Native Method) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:88) at at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:186) at at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at at java.io.File.length(File.java:910) at at ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy.isTriggeringEvent(SizeBasedTriggeringPolicy.java:59) at at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:170) at at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:441) at at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:413) at at ch.qos.logback.classic.Logger.info(Logger.java:603) at at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at at java.lang.reflect.Method.invoke(Method.java:601) at at org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:425) at at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:292) ... {code} (i) In this example the untrusted code domain is {{JRuby}}, which has evaluated a script that wrote a log message. This issue can be solved by marking the rollover call from within the LOGBack domain as _privileged_ using {{AccessController.doPrivileged()}}. As the rollover is actually triggered in {{RollingFileAppender#subAppend(E event)}} this should be straightforward. Instead of {code:lang=java} if (triggeringPolicy.isTriggeringEvent(currentlyActiveFile, event)) { rollover(); } {code} we could use {code:lang=java} AccessController.doPrivileged(new PrivilegedAction<Void>() { @Override public Void run() { if (triggeringPolicy.isTriggeringEvent(currentlyActiveFile, event)) { rollover(); } return null; } }); {code} to mark both the file read access in {{triggeringPolicy.isTriggeringEvent()}} as well as the write access in {{rollover()}} as _privileged_. (/) I will provide a simple pull request to fix this issue.
    via by Christian Brensing,
  • another HelloImpl/RMI problem
    via by malal...@my-deja.com,
    • java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/christian/foo/bar/logs/foo.log" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.internalCheckPermission(EquinoxSecurityManager.java:117) at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager$CheckPermissionAction.run(EquinoxSecurityManager.java:60) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:88) at org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager.checkPermission(EquinoxSecurityManager.java:186) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at java.io.File.length(File.java:910) at ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy.isTriggeringEvent(SizeBasedTriggeringPolicy.java:59) at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:170) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:441) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:413) at ch.qos.logback.classic.Logger.info(Logger.java:603) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:425) at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:292)

    Users with the same issue

    Unknown visitor1 times, last one,
    andyglick
    andyglick1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    71 more bugmates