Replacement of sun.reflect.Reflection#getCallerClass

[Jochen Theodorou]

Am 03.09.2013 05:04, schrieb Mandy Chung:
> Hi Nick,
>
> Thanks for the patch.
>
> JEP 176 [1] describes the caller-sensitive method and the need for a
> mechanical checking of caller-sensitive methods.  Also Peter Levart in
> [2] explained the change in MethodHandles.Lookup related to @CS.  I
> assume you understand the rationale behind and the potential security
> issues.  In general defining caller-sensitive API is discouraged.

The problem is, and the JDK itself shows that, that you sometimes cannot 
avoid caller-sensitive API. I thought that was clear by now. I am not 
the patch author, so understanding the potential security issues was not 
addressed to me, but I would like to understand them. So far I did hear 
only that if you have the Class object, you can do something, you 
normally cannot do. I would be interested in an example. Java security 
is really complicated to understand, and this would help to shed some 
light on the issue for others. Also I am wondering, if the Class object 
is a no-go, then how about class name and class loader? For Groovy we 
need the loader, but since we need to filter stack elements ourselves 
too, we also need the class names. A Class-object provides both, but I 
am sure almost all usages out there could work with the name and the 
loader only and if needed loading the class from the loader, with 
permissions set accordingly. Not sure how it is with internal class 
names here of course. AnonymousClassLoader would probably cause trouble 
here, but afaik that did not make it out of JSR292.

A different way to solve the issue was suggested as using an annotation 
to define frames which are not looked up by getCallerClass. But it did 
not get any interest. So I am really curious how you want to solve this.

> Defining a SE supported @CallerSensitive and also getCallerClass API
> poses the risk of "encouraging" developers to implement more @CS methods
> while not fully understand its implication.

Again I am curious... what is such an implication? That your method will 
behave different depending on from where it got called and, depending on 
if that is from an expected or unexpected source, you may get an 
expected or unexpected result here?

[...]
> 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int
> depth) method to:
>
>   * emulates the way ResourceBundle.getBundle(String, Locale) works.
>     Groovy runtime introduces intermediary stack frame between a caller
>     and the call to getBundle, these frames needs to be filtered out;
>     when looking for the caller classloader.
>   * support the annotation @Grab, @Grab allows to specify a dependency
>     between a code and a module (using apache ivy under the hood). The
>     resolution is done at runtime and require a specific Classloader
>     (the GroovyClassLoader), getCallerClass is used to find the class
>     loader of the caller, again filtering out the intermediary stack frame.
>
> Groovy 3.x has a different implementation that doesn't need to do stack
> walk to filter its runtime frames and find the caller.

To add here, I will build into Groovy 3.x the ability to transport the 
caller class from the Groovy class, that makes the call. So there will 
be no filtering and no magic caller class API at all. Still there will 
be several years we will have at least a Groovy 2.x out there.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org