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
