Upgrade to Log4J 2.18.0 #88237
Upgrade to Log4J 2.18.0 #88237
Conversation
ChrisHegarty
force-pushed
the
log4j_2_18_0
branch
from
b82281d to
3e70677
Compare
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
ChrisHegarty
added
:Core/Infra/Core
|
Hi @ChrisHegarty, I've created a changelog YAML for you. |
| @@ -124,11 +103,7 @@ public boolean implies(ProtectionDomain domain, Permission permission) { | |||
| if ("<<ALL FILES>>".equals(permission.getName())) { | |||
| hadoopHack(); | |||
| } | |||
| } else if (permission instanceof RuntimePermission | |||
| && "getClassLoader".equals(permission.getName()) | |||
| && isLoaderUtilGetClassLoaders()) { | |||
There was a problem hiding this comment.
Just to make sure I understand. THe clue of the problem was the getParent which did not have the permission?
https://issues.apache.org/jira/browse/LOG4J2-3236
Just calling LoaderUtil.getClassLoader is safe (I suppose yes, but can you do you know why)? because it is still used
https://github.com/apache/logging-log4j2/blob/log4j-2.18.0-rc1/log4j-api/src/main/java/org/apache/logging/log4j/util/LoaderUtil.java#L266
There was a problem hiding this comment.
Hmm... let me recheck this.
There was a problem hiding this comment.
You are right that LoaderUtil::getClassLoader is still present (in 2.18.0), and we can potentially suffer from the getParent issue which we ran into before. But it seems that all the call flows and tests do not encounter it. Since there are no plans to back port this, and all seems ok, I propose that we merge the change as is, but reserve the right to re-instate the workaround in ESPolicy if we encounter issues in the future.
Upgrade to log4J 2.18.0.
Remove two workarounds that are no longer needed (since the issues are not present in 2.18.0):