Replacement of sun.reflect.Reflection#getCallerClass

Nick Williams nicholas+openjdk at
Tue Sep 3 14:44:53 UTC 2013

On Sep 3, 2013, at 9:40 AM, David M. Lloyd wrote:

> 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.

Yes. Exactly. Thank you.

>>> 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
> -- 
> - DML

More information about the core-libs-dev mailing list