JDK-8217920 : Lookup.defineClass injects a class that can access private members of any class in its own module
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-01-28
  • Updated: 2020-01-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8173978 - Lookup.in should allow teleporting from a lookup class in a named module without dropping all access
Description
Lookup.defineClass should require PRIVATE access in order to inject a class as the resulting class can access private members of any class in its own module via core reflection, setAccessible is allowed if the injected class is in the same module as the definer class.
Comments
MethodHandles::privateLookupIn is designed to allow frameworks to elevate the privilege to get deep reflection access when the module authorizes the framework module by opening its package to it to access. In addition a framework can define auxiliary classes in an open package. To allow Lookup::defineClass on a Lookup returned from MethodHandles::privateLookupIn is important for frameworks (a supported replacement for `setAccessible` on ClassLoader::defineClass hack). Opening a package to a target module essentially grants full privileges that the target module can do deep reflection and injects classes. We should improve the documentation to help developers beware of the permissions given to when opening a package package to another module.
13-01-2020