[ 
https://issues.apache.org/jira/browse/LOG4J2-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378792#comment-17378792
 ] 

Paul Burrowes commented on LOG4J2-3117:
---------------------------------------

Thanks for the responses. Our specific use case is an application server that, 
amongst other things, runs SIP Servlets. Long-term we will need to adapt to the 
removal of the security manager but we will probably need to continue using it 
for much of the lifetime of Java 17.

 

This specific case, log rollover already has significant overhead from 
filesystem access so is least likely to suffer from the performance penalty of 
a call to the SecurityManager. Would you be averse to a PR containing the 
proposed fix or, as seems likely, yes, one that allows us to extend the 
RollingFileManager to introduce this call in our own code without maintaining a 
fork of RollingFileAppender? As observed, wrapping every log call in 
{{doPrivileged()}} would add unacceptable overhead.

> Log rollover throws AccessControlException if called from an unprivileged 
> context
> ---------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3117
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3117
>             Project: Log4j 2
>          Issue Type: Bug
>            Reporter: Paul Burrowes
>            Priority: Minor
>
> Similar to LOG4J2-150. When using a security manager, logging from an 
> unprivileged context can attempt to access system properties directly. 
> Attempting to hack around this with a custom {{RolloverStrategy}} shows that 
> other privileged actions such as creating files during rollover (done 
> directly in {{RollingFileManager}}) also fail. I believe rollover should be 
> performed inside a {{doPrivileged}} block to address these issues. 
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "user.dir" "read")
>         at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>         at 
> java.security.AccessController.checkPermission(AccessController.java:884)
>         at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>         at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294)
>         at java.lang.System.getProperty(System.java:717)
>         at java.io.UnixFileSystem.resolve(UnixFileSystem.java:133)
>         at java.io.File.getAbsolutePath(File.java:556)
>         at 
> org.apache.logging.log4j.core.appender.rolling.action.FileRenameAction.execute(FileRenameAction.java:161)
>         at 
> org.apache.logging.log4j.core.appender.rolling.action.FileRenameAction.execute(FileRenameAction.java:66)
>         at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:369)
>         at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:278)
>         at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:218)
>         at 
> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:267)
>         at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
>         at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
>         at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
>         at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
>         at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
>         at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
>         at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
>         at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403)
>         at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
>         at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
>         at org.apache.log4j.Category.maybeLog(Category.java:452)
>         at org.apache.log4j.Category.info(Category.java:262)
>         at MySipServlet.sendInviteToMediaServer(MySipServlet.java:614)
>         at MySipServlet.doInvite(MySipServlet.java:119)
>         at javax.servlet.sip.SipServlet.doRequest(Unknown Source)
>         at MySipServlet.doRequest(MySipServlet.java:768)
>         at javax.servlet.sip.SipServlet.service(Unknown Source)
>         at MyServletHandler$2.call(MyServletHandler.java:344)
>         at MyServletHandler$2.call(MyServletHandler.java:341)
>         at MyEventHandler.doInvocation(MyEventHandler:182)
>         at MyEventHandler.deliverEvent(MyEventHandler:154)
>         at MyEventHandler.processEvent(MyEventHandler:98)
>         at MyEventRouter.run(MyEventRouter:100)
>         at MyContextLogger$1.run(MyContextLogger:24)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at MyExecutorThreadFactory$1$1.run(MyExecutorThreadFactory:458)
>  {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to