[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877437#comment-15877437
]
Matt Sicker commented on LOG4J2-1820:
-------------------------------------
There's a check in LoaderUtil for the getClassLoader permission already. If you
don't have that, then good luck running almost anything that isn't fully custom
code.
With the security check for getting a ClassLoader, the possibility of a
ClassLoader being null (which indicates the root ClassLoader basically), and
various other edge cases, it almost makes me think that this is a class that
needs to be abstracted, though I think it'd probably be overkill.
> Log4j 2.8 can lose exceptions when a security manager is present
> ----------------------------------------------------------------
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.8
> Reporter: Jason Tedor
> Attachments:
> 0001-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader
> that it does not have permissions to access when a security manager is
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
