[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877454#comment-15877454
]
Matt Sicker commented on LOG4J2-1820:
-------------------------------------
Ok, I looked into the JDK7 source code for more details since the javadocs
didn't mention it. {{Class.forName(String)}} does not do any security manager
access checks at all. And technically, a getClassLoader permission check is
only needed when the calling class's ClassLoader is not the same as or a parent
of the target ClassLoader.
{quote}
If a security manager is present, and the caller's class loader is not null and
the caller's class loader is not the same as or an ancestor of the class loader
for the class whose class loader is requested, then this method calls the
security manager's checkPermission method with a
RuntimePermission("getClassLoader") permission to ensure it's ok to access the
class loader for the class.
{quote}
In that case, you could fall back to the calling class's ClassLoader I suppose.
Or a ClassLoader/Class.forName sort of abstraction (which could possibly help
with OSGi and other exotic ClassLoader environments).
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
