RFR 8014678: Spurious AccessControlException thrown in java.lang.Class.getEnclosingMethod()

[Paul Sandoz]

Hi,

Looks ok to me.

Paul.

On Feb 24, 2015, at 12:26 PM, Joel Borggrén-Franck <joel.franck at oracle.com> wrote:

> 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