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