RFR 8014678: Spurious AccessControlException thrown in java.lang.Class.getEnclosingMethod()
Joel Borggrén-Franck
joel.franck at oracle.com
Tue Feb 24 11:26:11 UTC 2015
Hi,
Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.
Consider the following classes:
class C {}
class A {
public void someMetod() {
class B {}
}
}
If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the “real” caller C has the correct permissions. So we and up with a call stack that looks like
Caller: Call:
j.l.Class(for A.class) A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
j.l.Class(for B.class) A.class::getDeclaredMethods(); // j.l.Class is the caller here
C B.class::getEnclosingMethod();
.... application code ….
The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
Webrev: http://cr.openjdk.java.net/~jfranck/8014678/
Bug is not open but the tests show how this is reproduced.
cheers
/Joel
More information about the core-libs-dev
mailing list