[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=17070576#comment-17070576
]
Uwe Schindler commented on LOG4J2-2761:
---
In the backport to the 2.x branch, you did not pick the commit fixing the other
test that also failed in a similar way (unrelated to the security manager
issue):
https://github.com/apache/logging-log4j2/commit/795472530157e2f39d9f97d965dde443cf56906a
Unfortunately, this commit did not have the issue number in the description -
sorry. But in fact it was only a test fix, so not sure if you want to backport
it. But for me this test fails when you have a whitespace in your Maven
repository (my .m2 folder is under my user name with whitespace) or if the
checkout is in a whitespaced folder.
At Lucene we have Jenkins tests that run the whole build in a folder with
whitespace.
> 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
> Fix For: 2.13.2
>
> Time Spent: 50m
> 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=17070562#comment-17070562
]
Uwe Schindler commented on LOG4J2-2761:
---
PR was applied correctly. I will check if Solr works correctly a bit later
using a snapshot release.
> 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
> Fix For: 2.13.2
>
> Time Spent: 50m
> 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=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] [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=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
>
