RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup
Mandy Chung
mandy.chung at oracle.com
Wed Nov 13 19:07:51 UTC 2019
On 11/13/19 6:10 AM, Johannes Kuhn wrote:
> On 11.11.2019 22:23, Mandy Chung wrote:
>> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends
>> to test if this lookup is a full-power lookup; that is created by the
>> original caller class calling MethodHandles::lookup. The current
>> specification for Lookup::hasPrivateAccess returns true if the lookup
>> modes contain PRIVATE but it does not check MODULE bit.
>>
>> This patch also clarifies the capabilities w.r.t PRIVATE access and
>> full-power access. The security permission check is performed if the
>> Lookup is not a full power lookup and therefore Lookup::defineClass
>> spec should be updated to perform security permission check if the
>> security manager is present and this lookup refuses access,
>> consistent with other Lookup operations.
>>
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
>>
>> thanks
>> Mandy
>
> Thank you for all those changes. It fixed two of my reported bugs
> (JDK-8209005, JDK-8209078).
Thanks for filing these good reports. JDK-8173978 resolved the issues
reported by JDK-8209005 and JDK-8209078.
> It also makes my suggested workaround for JDK-8230636 not longer
> possible. Thanks for picking that up too.
>
> I just have a question about the requirement of
> MethodHandles.privateLookupIn: As it requires that the originating
> lookup has both PRIVATE and MODULE access, it sounds a lot like full
> privilege access. Should this be reworded?
>
The two bullets about the caller lookup object must have MODULE and
PRIVATE are important explanation for it to require such access.
Maybe I can add a bullet to say "The caller lookup object must have full
privilege access" and then move those two bullets as sub-bullets under it.
What do you think?
> Also, with the current specification, I don't see a way to abuse
> jdk.unsupported's privileged access into java.base (which IMHO caused
> the entire rework).
Thanks for looking at this.
Mandy
More information about the core-libs-dev
mailing list