Replacement of sun.reflect.Reflection#getCallerClass

Mandy Chung mandy.chung at
Tue Sep 3 19:21:14 UTC 2013

On 9/3/13 11:11 AM, Peter Levart wrote:
> On 09/03/2013 07:41 PM, David M. Lloyd wrote:
>>> What about a simple restriction on methods returning such instances 
>>> that
>>> Class objects are only returned when they are resolvable from the
>>> ClassLoader of client code. If they are not resolvable, null is
>>> returned. For example, the equivalent of:
>> I don't think this will hold up.  Why would (for example) a logging 
>> API have access to every class loader that might need to log 
>> something?  In any system of appreciable size, there is typically at 
>> least *some* class loader isolation, often a lot of it.  Utilities 
>> like logging or security code that need to do this kind of check do 
>> not typically have direct access to classes which are "higher on the 
>> stack", so to speak. 
> Ok, I understand. What about the other way around - would this be 
> acceptable from security perspective (asking Mandy?):

I don't think that works for log4j either.  In general we should only 
allow a ClassLoader A to access classes loaded by a ClassLoader B only 
if B trusts A (i.e A is the same or an ancestor of B); otherwise some 
kind of permission check (e.g. package access) is required.    Log4j 
wants to access all Class instances on the stack for diagnosibility 
purpose and unless Log4j is loaded by the bootstrap class loader (put 
-Xbootclasspath) it may not be able to get access to all classes via 
Class.forName call.

This would probably need a coarse-grained permission than a fine-grained 
permission check on the indivdual stack frame subject to the 


> - If you can see me (by name), then you're exposed (I can get you):
> public class StackTraceFrame {
>     private final Class<?> declaringClass;
>     @CallerSensitive
>     public Class<?> getDeclaringClass() {
>         try {
>             Class<?> cc = Reflection.getCallerClass();
>            return Class.forName(cc.getName(),
>                                  false,
> declaringClass.getClassLoader())
>                    == cc ? declaringClass : null;
>         } catch (ClassNotFoundException ignore) {}
>         return null;
>     }
> This would not present a problem for JDK system classes since they can 
> not see client code.

More information about the core-libs-dev mailing list