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
