Replacement of sun.reflect.Reflection#getCallerClass

[Jochen Theodorou]

Am 04.09.2013 02:33, schrieb Mandy Chung:
> On 9/3/13 1:17 AM, Jochen Theodorou wrote:
>>> 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?
>
> *and* this could lead to surprises and hard-to-diagnose issue to any
> framework/library or even another API provided in the same library
> calling a caller-sensitive method that can't tell if they get the true
> caller or not.
>
> Caller-sensitivity is used in getting the right visibility (e.g.
> Resource.getBundle and Class.forName) and for security checks.  The
> platform's caller-sensitive methods involve both visibility and
> security.  For the former (visiability): the use cases of getCallerClass
> are mostly for gaining visibility to avoid having the client code to
> supply the appropriate ClassLoader or Class. Such convenience has led to
> the existing stack walking code to search for a ClassLoader that it can
> find what the client code is asking for - it's not impossible that it
> might find the wrong ClassLoader but that happens to find a resource
> with the same name.  For the latter (security), caller sensitive methods
> have kept us having "so much fun" in the past CPU releases.

If you want to avoid such surprises and hard-to-diagnose issues, then 
you have to deprecate the convinience versions of Resource.getBundle and 
Class.forName. The new @CS will not change a bit of that misleading 
behaviour. As for the security... the whole ProtectionDomain and 
permissions system is highly caller sensitive. Again, that will not be 
changed, unless you want a completely new security model. So what is it 
you want me to tell? That making a public API for this will make things 
even worse? Then we don't need this discussion here.

Even if you for example did the following and let's say introduce an 
annotation to mark a method that it should appear when I call 
getCallerClass, and everything else will not. Even then you might not 
get the expected caller, since a framework may use that in between 
somehow or by accident. And even if you gave the annotation for example 
a class as kind of key and use that key for getCallerClass to return 
only the last frame with that annotation, that used the specified key... 
I guess that would ensure predictable behaviour, but is far from 
convenient... Anyway, if the key is known somehow, you can still gain access

> Groovy/log4j and other existing framework has already dealt with such
> problem and written some non-trivial code to solve this problem.  My
> point is more about the general app developers that need education and
> big warning in the documentation before they attempt learning this API
> to get the immediate caller.

Sure, I am all for big warnings...

> Couple months ago a few of us discussed
> some security issues we had fixed in the past and evaluated what we
> could do about them - one thing we want to do is to remove the caller
> sensitive-ness.  This is certainly a big big change and high
> compatibility risk - some future work.  Just to give you a sense how
> serious we are the security issue around caller-sensitive methods.

So Java will maybe get a new security model?

> I'm happy to know that you will build into Groovy 3.x the ability to
> transport the caller class from the Groovy class.  I strongly believe
> this is the right thing to do and use the ResourceBundle.getBundle and
> Class.forName with the ClassLoader parameter. No filtering and no magic
> caller class API as you said.

Well, Groovy 3.x will be a breaking change - one we intended to do 
anyway. So we are free to incorporate a fix for this with our abilities 
and independent of the VM. We don't really like to depend on sun.* 
packages, but sometimes there is just no way around. And this is not 
about the big breaking change, it is about how an existing framework can 
release a new version of its framework, that is compatible to the old 
versions, but has the replacement for getCallerClass. Such existing 
usages constrain the solution space quite a lot.

> I have replied to Nick's patch with the focus on the ability to get
> Class instance from stack trace for diagnosability purpose.  I will soon
> bring up the discussion on the ability to get caller's Class /
> ClassLoader use case.

I am looking forward to that

bye blackdrag

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