On 07/20/2013 03:41 AM, Mandy Chung wrote:
Peter,
FYI. I have filed this RFE:
8020968: Load resource files using the caller's class and class loader
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020968
Mandy
Hi Mandy,
I wonder what API you had in mind. Currently we have ClassLoader and
Class instance methods to load resources which are quite low-level in
the sense that they require full or relative path to the resource and
they return either URL or InputStream. So they usually get wrapped by
utilities implementing special search strategies and/or resource
un-marshaling.
For example, imagine one would like to locate resource using the caller
class' ClassLoader using the resource path composed of the package name
of the caller class replacing dots with slashes and specified resource
name appended, then load the content of the resource into a
BufferedImage and construct an Icon from it, wrapping any IOException
thrown with some unchecked exception:
package my.pkg;
class MyClass {
void someMethod() {
// a static utility method:
Icon saveIcon = Resources.getIcon("save-icon.png");
// that does the following:
Icon saveIcon;
try {
saveIcon = new
ImageIcon(ImageIO.read(MyClass.class.getResource("save-icon.png")));
} catch (IOException e) {
throw new RuntimeException(e);
}
I don't suggest creating such APIs in the JDK, just enabling them. So
what would it take for an API in ClassLoader or Class to enable creating
an API like Resources.getIcon() presented above?
I guess a static method like Class.getCallerClass() would do, but I have
a feeling this is something that is flagged as sensitive by the security
team, right?
So what about Class.getCallerClassResource(String name)? This would not
locate the resource on behalf of the directly calling class, but the
class that is calling some method that is calling this method.
Regards, Peter
P.S. I still don't know why would method like Class.getCallerClass() be
so security sensitive? In order for the getCallerClass() to succeed the
method calling it would have to be annotated with @CallerSensitive
annotation. If a method has such annotation, anyone deciding to call
such method is warned in advance that this method is "extracting" the
callers class and using it as it finds fit. There's no danger of
untrusted code to sneak it's own @CallerSensitive methods so that
unaware code calls them or is it? Does @CallerSensitive work on
statically resolved methods or on runtime resolved methods? I mean, if
there is some code in some security-sensitive class:
Runnable r = ....
r.run();
// where a Runnable instance is provided by untrusted code:
class EvilRunnable implements Runnable {
@Override
@CallerSensitive
public void run() {
Class<?> caller = Class.getCallerClass();
// do some things with caller....
}
}
Would @CallerSensitive have desired effect as it is implemented
currently or would it work only if Runnable.run() interface method was
annotated?
On 6/25/2013 6:50 PM, Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK
internal usage, so it's use is limited to classes loaded by bootstrap
or extension class-loaders. In JDK-internal code it is used mainly
for implementing security-sensitive decisions. But since the
sun.reflect.Reflection.getCallerClass(int) was public and
unrestricted, it found it's way out into user code, where at least I
know that it is used in two areas:
1 - to locate callers in the whole call-stack so that their location
in class-path can be reported (Log4J is an example)
2 - to locate immediate caller so that some resources associated with
it can be located and used (for example localization data in GUI
applications)
I don't know how wide-spread 1st usecase is, but the 2nd is common,
since it's use enables APIs that need not explicitly pass-in the
calling class in order to locate resources associated with it (and/or
the class-loader of it). So it would be nice to have such supported
API in JDK8 at least.
I'm asking here, to hear any arguments against making such API
supported and public. Are there any security or other issues? If
there aren't, what steps should be taken to introduce such API in the
JDK8 timeframe? I'm thinking of a no-arg method, say
j.l.Class.getCaller() and moving @CallerSensitive to a supported
package + enabling it to mark methods in any class (not just system
and ext classes)...
Regards, Peter
