Replacement of sun.reflect.Reflection#getCallerClass

David M. Lloyd david.lloyd at
Tue Sep 3 14:40:04 UTC 2013

On 09/03/2013 09:30 AM, Mandy Chung wrote:
> On 9/3/2013 5:52 AM, Nick Williams wrote:
>> Do, I don't understand the rationale. Alan said the security issues
>> couldn't be discussed openly. I can get a Class object MANY different
>> ways without a security check. I don't see or understand any
>> vulnerabilities here. I'm going to need much more information in order
>> to contribute to the discussion in an informed manner.
> The Java security guideline is a good starting point.

Spelling this out for clarity.  This document talks about using access 
modifiers to restrict class definitions, which I think everyone agrees 
is a reasonable security measure.  It specifically does *not* address 
accessing java.lang.Class instances, which are not protected or guarded 
in any way as far as I can see, and are as easy to access as .getClass() 
on any Object instance.  In other words, if you have an object, you have 
its Class instance as well.

The document *does* cover the (existing) protection of requiring a 
runtime permission to access the class loader from a Class (or other ways).

Again, the doc talks about protecting ClassLoader instances, *not* Class 
instances.  If accessing Class instances is a security hole, then we 
already have a serious problem that has nothing to do with this.

>> And, has been stated many, many times, this non-goal is incompatible
>> with the community's needs. Now, there /is/ a way to avoid making
>> @CallerSensitive public (which the community doesn't care about) while
>> still making getCallerClass public (which is really what the community
>> needs). In order to do so, you must remove the check that requires the
>> method calling getCallerClass/getCallerFrame to be annotated with
>> @CallerSensitive. Once you remove that check, you don't need
>> @CallerSensitive to be public. To be clear, though, once you remove
>> that check, you don't need @CallerSensitive /at all/. It can simply go
>> away.
> Do you mean sun.reflect.CallerSensitive can go away?  This is very
> important part of the design that we need to detect which methods are
> caller-sensitive.   I keep seeing you suggest this and it is unclear to
> me if you only mean to remove java.lang. at CallerSensitive in your proposal.
> Mandy


More information about the core-libs-dev mailing list