RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK (original) (raw)
Peter Levart peter.levart at gmail.com
Thu Mar 21 18:47:38 UTC 2013
- Previous message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Next message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 03/21/2013 07:11 PM, Mandy Chung wrote:
Hi Peter,
On 3/20/2013 2:33 AM, Peter Levart wrote: Hi,
If I understand correctly, sun.reflect.Reflection.getCallerClass(int) will not be usable by non-system code any more. I know it's not a public API, but it's useful in some situations (not security-related) and there's no public API for that functionality. Do you have any example of existing use of Reflection.getCallerClass to find immediate caller class? or does it need to walk the stack? That'd be useful.
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...
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?
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?
Regards, Peter
Mandy
Regards, Peter On 03/15/2013 04:31 AM, Christian Thalinger wrote: [This is the HotSpot part of JEP 176]
http://cr.openjdk.java.net/~twisti/7198429 7198429: need checked categorization of caller-sensitive methods in the JDK Reviewed-by: More information in JEP 176: http://openjdk.java.net/jeps/176 src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/javaClasses.hpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/classfile/vmSymbols.hpp src/share/vm/oops/method.cpp src/share/vm/oops/method.hpp src/share/vm/opto/librarycall.cpp src/share/vm/prims/jvm.cpp src/share/vm/prims/methodHandles.cpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/vframe.cpp src/share/vm/runtime/vframe.hpp
- Previous message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Next message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]