RFR(S) 8166304: Skipping access check for classes generated by core reflection

Robbin Ehn robbin.ehn at oracle.com
Wed Nov 16 09:49:56 UTC 2016


Hi Harlod,

Is there a reason for not doing a return after the exception is thrown?
+         Exceptions::fthrow(
+           THREAD_AND_LOCATION,
+           vmSymbols::java_lang_IllegalAccessError(),
+           "class %s loaded by %s cannot access jdk/internal/reflect superclass %s",
+           this_klass->external_name(), this_cld->loader_name(), super->external_name());
---->       return; ????
+       }
+     }

/Robbin

On 11/15/2016 03:09 PM, harold seigel wrote:
> Hi,
>
> Please review this fix for bug JDK-8166304.  The fix throws an IllegalAccessError exception when attempting to create a class that is a sub-type of a jdk.internal.reflect
> class, unless the class loader is either the boot loader or the special reflection class loader.  This prevents user classes from being able to extend jdk.internal.reflect
> classes in order to bypass Reflection.getCallerClass.
>
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8166304/
>
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8166304
>
> The fix was tested with the JCK Lang and vm tests, the JTreg hotspot, java/io, java/lang, and java/util tests, the nsk co-located and the non-co-located tests, the RBT
> tier2 tests, and the test in the webrev.
>
> A sample error message looks like this:
>
> java.lang.IllegalAccessError: class FakeMethodAccessor loaded by jdk/internal/loader/ClassLoaders$AppClassLoader cannot access jdk/internal/reflect superclass
> jdk.internal.reflect.MethodAccessorImpl
>
> Thanks, Harold
>


More information about the hotspot-runtime-dev mailing list