RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

[Mandy Chung]

Hi Peter,

On 3/21/2013 11:47 AM, Peter Levart wrote:
> ...
>
> I have seen a utility that uses it to establish the context (package 
> and ClassLoader) of where to start searching for resources for GUI 
> components construction. And a utility that wraps 
> Class.forName(String) - specifying Class.forName(name, true, 
> Reflection.getCallerClass(2).getClassLoader()) instead to use the 
> caller's class loader to load the class...
>

This seems to me that this case is more of visibility issue rather than 
caller-sensitivity.

> Usually it is only necessary to get the immediate caller.
>
>>
>>> Is there a reason to not "unofficially" support also classes with 
>>> @CS annotated methods and which are not loaded by bootstrap or 
>>> extension class-loader ?
>>
>> We expect that most of the caller-sensitive cases are in the JDK and 
>> should be rare for non-system libraries to have caller-sensitive 
>> code.  It'd be good to understand the use cases and the requirements 
>> to determine the appropriate support for it.
>
> Ok, but why limit? Is it an optimization?

Just out of scope and there will be much more consideration to expand 
the scope to cover the user caller-sensitive methods (e.g. SE API and 
implementable by different JDK vendors).

The scope of JEP 176 is target for the system code where it has all 
permissions that we expect majority of the caller-sensitive cases are in.

>
> Is it for security? For example: one might think that creating an 
> anonymous class and holding a j.l.Class reference somewhere safe is 
> enough for safety, so the class itself could have public API. Now if 
> an untrusted callback object is passed to the code of such class and 
> it is invoked from within that code, the anonymous class can get 
> "revealed" to the untrusted code which can use it's public API to 
> invoke it. Are there any other implications of allowing non-system 
> code to get the caller?

It'd help if you can have a test case showing this to help the 
discussion.  However, restricting Reflection.getCallerClass be called by 
the system code is no difference than defining a module-private class.  
sun.reflect.* classes are private to the JDK implementation that are not 
supported.  If there were modules, applications would not have been able 
to call it since sun.reflect would not be exported.

I would recommend to file a RFE and describe the use cases that require 
an API to get the caller class or find caller's context so that we can 
address it properly.

With this fix, the only way to call Reflection.getCallerClass must be 
system code (in bootclasspath or extension library).   As a workaround, 
can you put it on the bootclasspath?

Mandy