Hi,
Looks ok to me.
Paul.
On Feb 24, 2015, at 12:26 PM, Joel Borggrén-Franck <joel.fra...@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
