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).
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?
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,
Johannes
