[GitHub] [logging-log4j2] Kuojian21 opened a new pull request #352: fix bug:support includeLocation for AsyncLogger
Kuojian21 opened a new pull request #352: fix bug:support includeLocation for AsyncLogger URL: https://github.com/apache/logging-log4j2/pull/352 This bug cause that the "%L" is invalid for AsyncLogger. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [logging-log4j2] Kuojian21 closed pull request #352: fix bug:support includeLocation for AsyncLogger
Kuojian21 closed pull request #352: fix bug:support includeLocation for AsyncLogger URL: https://github.com/apache/logging-log4j2/pull/352 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067232#comment-17067232 ] Uwe Schindler edited comment on LOG4J2-2761 at 3/26/20, 12:01 AM: -- FYI, the test failure was a similar problem in one test: {{GcFreeLoggingTestUtil#agentJar()}} was incorrectly parsing an URL/URI. Same issue. IMHO, the whole codebase of log4j should really be reviewed about incorrect conversion between URI/URL and file system paths. You can't do that by simple string transformations. Use File/Path classes and URI to do the conversion - always with same pattern. Don't do things like stripping away "file:" and then treat the rest as file path! Maybe log4j should use forbiddenapis maven plugin like many other ASF projects to detect use of unsafe methods from Java's API. was (Author: thetaphi): FYI, the test failure was a similar problem in one test: {{GcFreeLoggingTestUtil#agentJar()}} was incorrectly parsing an URL/URI. Same issue. IMHO, the whole codebase of log4j should really be reviewed about incorrect conversion between URI/URL and file system paths. You can't do that by simple string transformations. Use File/Path classes and URI to do the conversion - always with same pattern. Don't do things like stripping away "file:" and then teat the rest as file path! Maybe log4j should use forbiddenapis maven plugin like many other ASF projects to detect use of unsafe methods from Java's API. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067232#comment-17067232 ] Uwe Schindler commented on LOG4J2-2761: --- FYI, the test failure was a similar problem in one test: {{GcFreeLoggingTestUtil#agentJar()}} was incorrectly parsing an URL/URI. Same issue. IMHO, the whole codebase of log4j should really be reviewed about incorrect conversion between URI/URL and file system paths. You can't do that by simple string transformations. Use File/Path classes and URI to do the conversion - always with same pattern. Don't do things like stripping away "file:" and then teat the rest as file path! Maybe log4j should use forbiddenapis maven plugin like many other ASF projects to detect use of unsafe methods from Java's API. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067220#comment-17067220 ] Uwe Schindler edited comment on LOG4J2-2761 at 3/25/20, 11:31 PM: -- I opened PR @ https://github.com/apache/logging-log4j2/pull/355 It fixes the following things in {{FileUtils.fileFromUri}}: Rewrite logic to handle 2 cases: - Absolute URI: if it has scheme "vfsfile" patch it to be "file" (this goes back to very long time ago when jboss URIs are supported to track file changes) - Absolute URI: if it has scheme "file", just convert it to a File with {{new File(uri)}}. No further parsing, This is fully standards compliant with escapes - Relative URI: Do the same like in old code, but wrap everything in the try/catch. This ensures that if a SecurityException happens on File.exist() it is not breaking. Previously not all parts were shielded by try/catch. Tests for log4j-core pass for me on windows (with whitespace), I only have an unrelated test failure (possibly windows-caused). I can't run all tests as somehow it complains about not able to compile the module descriptor, although my setup looks correct. I also added new tests and removed the broken test with the existing/non-existing "+". This was just plain wrong (and it failed on Jenkins from time to time, because it was incorrect). was (Author: thetaphi): I opened PR @ https://github.com/apache/logging-log4j2/pull/355 It fixes the following things in {{FileUtils.fileFromUri}}: Rewrite logic to handle 2 cases: - Absolute URI: if it has scheme "vfsfile" patch it to be "file" (this goes back to very long time ago when jboss URIs are supported to track file changes) - Absolute URI: if it has scheme "file", just convert it to a File with {{new File(uri)}}. No further parsing, This is fully standards compliant with escapes - Relative URI: Do the same like in old code, but wrap everything in the try/catch. This ensures that if a SecurityException happens on File.exist() it is not breaking. Previously not all parts were shielded by try/catch. Tests for log4j-core pass for me on windows (with whitespace), I only have an unrelated test failure (possibly windows-caused). I can't run all tests as somehow it complains about not able to compile the module descriptor, although my setup looks correct. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at >
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067220#comment-17067220 ] Uwe Schindler commented on LOG4J2-2761: --- I opened PR @ https://github.com/apache/logging-log4j2/pull/355 It fixes the following things in {{FileUtils.fileFromUri}}: Rewrite logic to handle 2 cases: - Absolute URI: if it has scheme "vfsfile" patch it to be "file" (this goes back to very long time ago when jboss URIs are supported to track file changes) - Absolute URI: if it has scheme "file", just convert it to a File with {{new File(uri)}}. No further parsing, This is fully standards compliant with escapes - Relative URI: Do the same like in old code, but wrap everything in the try/catch. This ensures that if a SecurityException happens on File.exist() it is not breaking. Previously not all parts were shielded by try/catch. Tests for log4j-core pass for me on windows (with whitespace), I only have an unrelated test failure (possibly windows-caused). I can't run all tests as somehow it complains about not able to compile the module descriptor, although my setup looks correct. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?focusedWorklogId=409962=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409962 ] ASF GitHub Bot logged work on LOG4J2-2761: -- Author: ASF GitHub Bot Created on: 25/Mar/20 23:23 Start Date: 25/Mar/20 23:23 Worklog Time Spent: 10m Work Description: uschindler commented on pull request #355: LOG4J2-2761: Fix FileUtils#fileFromUri to works correctly with Securi… URL: https://github.com/apache/logging-log4j2/pull/355 …tyManager and also fix URI parsing to behave sane with standards This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 409962) Remaining Estimate: 0h Time Spent: 10m > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [logging-log4j2] uschindler opened a new pull request #355: LOG4J2-2761: Fix FileUtils#fileFromUri to works correctly with Securi…
uschindler opened a new pull request #355: LOG4J2-2761: Fix FileUtils#fileFromUri to works correctly with Securi… URL: https://github.com/apache/logging-log4j2/pull/355 …tyManager and also fix URI parsing to behave sane with standards This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066910#comment-17066910 ] Ralph Goers commented on LOG4J2-2761: - PRs are always welcome. Just please make sure you run a full build so all the unit tests can run. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066879#comment-17066879 ] Uwe Schindler commented on LOG4J2-2761: --- No problem, if you need a bit of review or help, I can take place. I am not so familar with log4j2 code, so I did not try to fix it myself. If you are OK with the ideas here, I can also try to create a PR. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Assignee: Ralph Goers >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066796#comment-17066796 ] Ralph Goers commented on LOG4J2-2761: - [~uschindler] Thanks for the info. That is most helpful. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066794#comment-17066794 ] Uwe Schindler commented on LOG4J2-2761: --- LOG4J2-466 is only caused by the problem with the "+" sign decoded in URLDecoder. If you convert the URI/URL to a File using {{new File(URI)}} this won't happen. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066792#comment-17066792 ] Uwe Schindler edited comment on LOG4J2-2761 at 3/25/20, 4:11 PM: - bq. I am not really sure what to do with this issue. Log4j is simply calling File.exists(). Java itself is calling the security manager. You should be able to duplicate this against any file running with the same security manager without Log4j in the picture. The issue is that File.exists() with a file that have "%20" or similar encodings in the name catches SecurityManager as this path is simply not allowed to be accessed. There's no workaround. When security manager is effective you are not even allowed to check for existence of a file that is outside your sandbox. Plain easy. Read my comment why its happening previously. was (Author: thetaphi): bq. I am not really sure what to do with this issue. Log4j is simply calling File.exists(). Java itself is calling the security manager. You should be able to duplicate this against any file running with the same security manager without Log4j in the picture. The issue is that File.exists() with a file that have "%20" or similar encodings in the name catches SecurityManager as this path is simply not allowed to be accessed. There's no workaround. When security manager is effective you are not even allowed to check for existence of a file that is outside your sandbox. Plain easy. Read my comment previously. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066792#comment-17066792 ] Uwe Schindler edited comment on LOG4J2-2761 at 3/25/20, 4:11 PM: - bq. I am not really sure what to do with this issue. Log4j is simply calling File.exists(). Java itself is calling the security manager. You should be able to duplicate this against any file running with the same security manager without Log4j in the picture. The issue is that File.exists() with a file that have "%20" or similar encodings in the name catches SecurityManager as this path is simply not allowed to be accessed (because the path with %20 does not exist and is not whitelisted). There's no workaround. When security manager is effective you are not even allowed to check for existence of a file that is outside your sandbox. Plain easy. Read my comment why its happening previously. was (Author: thetaphi): bq. I am not really sure what to do with this issue. Log4j is simply calling File.exists(). Java itself is calling the security manager. You should be able to duplicate this against any file running with the same security manager without Log4j in the picture. The issue is that File.exists() with a file that have "%20" or similar encodings in the name catches SecurityManager as this path is simply not allowed to be accessed. There's no workaround. When security manager is effective you are not even allowed to check for existence of a file that is outside your sandbox. Plain easy. Read my comment why its happening previously. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066792#comment-17066792 ] Uwe Schindler commented on LOG4J2-2761: --- bq. I am not really sure what to do with this issue. Log4j is simply calling File.exists(). Java itself is calling the security manager. You should be able to duplicate this against any file running with the same security manager without Log4j in the picture. The issue is that File.exists() with a file that have "%20" or similar encodings in the name catches SecurityManager as this path is simply not allowed to be accessed. There's no workaround. When security manager is effective you are not even allowed to check for existence of a file that is outside your sandbox. Plain easy. Read my comment previously. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:687) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708) > at > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45) > at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) > at > org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138) > {code} > policy file contains the following permissions: > {code} > grant codeBase "file:${catalina.home}/webapps/navigator/-" { > permission java.io.FilePermission "${catalina.home}/-", "read"; > permission java.io.FilePermission "${catalina.home}/", "read"; > }; > {code} > where catalina.home is "C:\My Space\apache-tomcat-9.0.30" > It is related to LOG4J2-466 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066789#comment-17066789 ] Uwe Schindler edited comment on LOG4J2-2761 at 3/25/20, 4:06 PM: - Hi, this issue hurted us several times with Solr (but also Elasticsearch). See SOLR-14362 for an example. Apache Lucene/Solr tests run inside a security manager, Apache Solr also and Elasticsearch has a security manager and policy for every plugin. The policy is very restrictive and does not allow any read/write access outside the home folder of Solr/Elasticsearch and while running tests, every test is completely restricted to its working directory. In most cases you can work around that issue by explicitely passing a -Dlog4j.configurationFile with a real filename (no URI or whatever). But as soon as you have something like a URI from ClassLoader (because by default log4j is searching for the config file in classpath), you are lost: If the classes (that's usual in tests) are in a file system folder which has a whitespace in the name, log4j does the following: - It calls {{classloader.getResource("log4j2.xml")}} this returns an URL - It reads the URL using its InputStream (which is all fine), but for some reason it also calls the method FileUtils#fileFromUri() using a fully valid resource URL. - The correct way would be to throw away that method and just use {{new File(url.toURI())}}. E.g. see a nice comment in the Maven docu about this: http://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths Sorry to be a bit harsh here: fileFromUri() looks like a method from the early days of Java and Log4j1, never touched and broken to hell (to hell to hell!!!). It does so many shitty things, which is against all standards, just to try to convert an URL to a File object. I agree that some parts of the code should be OK to do when parsing user-supplied URLs (e.g. if you have just a relative path name or relative file URI), but all this JBOSS and escaping/unescaping to try to do file.exist() is - sorry - not acceptable and breaks too easy. In short: - Nuke most of that method and only use it to parse URLs coming from config files. The part with relative paths at begin is OK, but when you detected that it's a valid absolute URL it should not try to be clever - especially it should never do I/O with File.exist()! You need to catch SecurityException(), as calling exists() may not be allowed. But to make it easy, use the "official" way shown below. - When loading the log4j from the classpath (ConfigurationSource.fromResource) don't call this method at all. You can 100% be sure that the URL is correctly formatted. Maybe just check that it's a "file"-URL. The only correct way to convert an URL to a file is new File(url.toURI()). FYI, URL#getFile() is a "forbidden method" in code from the Lucene community. We disallow any class we compile to call it really anywhere! The problem with this method is that it DOES NOT convert an URL to a File, its name is misleading. was (Author: thetaphi): Hi, this issue hurted us several times with Solr (but also Elasticsearch). See SOLR-14362 for an example. Apache Lucene/Solr tests run inside a security manager, Apache Solr also and Elasticsearch has a security manager and policy for every plugin. The policy is very restrictive and does not allow any read/write access outside the home folder of Solr/Elasticsearch and while running tests, every test is completely restricted to its working directory. In most cases you can work around that issue by explicitely passing a -Dlog4j.configurationFile with a real filename (no URI or whatever). But as soon as you have something like a URI from ClassLoader (because by default log4j is searching for the config file in classpath, you are lost: If the classes (that's usual in tests) are in a file system folder which has a whitespace in the name, log4j does the following: - It calls {{classloader.getResource("log4j2.xml")}} this returns an URL - It reads the URL using its InputStream (which is all fine), but for some reason it also calls the method FileUtils#fileFromUri() using a fully valid resource URL. - The correct way would be to throw away that method and just use {{new File(url.toURI())}}. E.g. see a nice comment in the Maven docu about this: http://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths Sorry to be a bit harsh here: fileFromUri() looks like a method from the early days of Java and Log4j1, never touched and broken to hell (to hell to hell!!!). It does so many shitty things, which is against all standards, just to try to convert an URL to a File object. I agree that some parts of the code should be OK to do when parsing user-supplied URLs (e.g. if you have just a relative path name or relative file URI),
[jira] [Commented] (LOG4J2-2761) log4j2 fails when a whitespace is in the file path and Java security manager is used
[ https://issues.apache.org/jira/browse/LOG4J2-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066789#comment-17066789 ] Uwe Schindler commented on LOG4J2-2761: --- Hi, this issue hurted us several times with Solr (but also Elasticsearch). See SOLR-14362 for an example. Apache Lucene/Solr tests run inside a security manager, Apache Solr also and Elasticsearch has a security manager and policy for every plugin. The policy is very restrictive and does not allow any read/write access outside the home folder of Solr/Elasticsearch and while running tests, every test is completely restricted to its working directory. In most cases you can work around that issue by explicitely passing a -Dlog4j.configurationFile with a real filename (no URI or whatever). But as soon as you have something like a URI from ClassLoader (because by default log4j is searching for the config file in classpath, you are lost: If the classes (that's usual in tests) are in a file system folder which has a whitespace in the name, log4j does the following: - It calls {{classloader.getResource("log4j2.xml")}} this returns an URL - It reads the URL using its InputStream (which is all fine), but for some reason it also calls the method FileUtils#fileFromUri() using a fully valid resource URL. - The correct way would be to throw away that method and just use {{new File(url.toURI())}}. E.g. see a nice comment in the Maven docu about this: http://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths Sorry to be a bit harsh here: fileFromUri() looks like a method from the early days of Java and Log4j1, never touched and broken to hell (to hell to hell!!!). It does so many shitty things, which is against all standards, just to try to convert an URL to a File object. I agree that some parts of the code should be OK to do when parsing user-supplied URLs (e.g. if you have just a relative path name or relative file URI), but all this JBOSS and escaping/unescaping to try to do file.exist() is - sorry - not acceptable and breaks too easy. In short: - Nuke most of that method and only use it to parse URLs coming from config files. The part with relative paths at begin is OK, but when you detected that it's a valid absolute URL it should not try to be clever - especially it should never do I/O with File.exist()! You need to catch SecurityException(), as calling exists() may not be allowed. But to make it easy, use the "official" way shown below. - When loading the log4j from the classpath (ConfigurationSource.fromResource) don't call this method at all. You can 100% be sure that the URL is correctly formatted. Maybe just check that it's a "file"-URL. The only correct way to convert an URL to a file is new File(url.toURI()). FYI, URL#getFile() is a "forbidden method" in code from the Lucene community. We disallow any class we compile to call it really anywhere! The problem with this method is that it DOES NOT convert an URL to a File, its name is misleading. > log4j2 fails when a whitespace is in the file path and Java security manager > is used > > > Key: LOG4J2-2761 > URL: https://issues.apache.org/jira/browse/LOG4J2-2761 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Windows 7/10, Java 8/11/13 with configured Java Security > Manager >Reporter: Yury Molchan >Priority: Major > > {code} > SEVERE: Error configuring application listener of class > [org.yurkom.navigator.web.servlet.StartupListener] > java.security.AccessControlException: access denied ("java.io.FilePermission" > "C:\My%20Space\apache-tomcat-9.0.30\webapps\navigator\WEB-INF\classes\log4j2.properties" > "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.checkRead(SecurityManager.java:888) > at java.io.File.exists(File.java:814) > at > org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88) > at > org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:360) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:527) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:456) > at > org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:318) > at >
[GitHub] [logging-log4j2] javieraviles opened a new pull request #354: DOCUMENTATION change. Adding target to Console appender in YAML config
javieraviles opened a new pull request #354: DOCUMENTATION change. Adding target to Console appender in YAML config URL: https://github.com/apache/logging-log4j2/pull/354 Console appender requires target property in order to work for YAML configuration This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services