On 13.11.2019 20:07, Mandy Chung wrote:
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.
I'm happy I could help.
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?
This is a good idea, because full privilege access is a new concept, and
should be mentioned at the places where it is used.
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
Shameless plug: I once asked on Stackoverflow if untrusted code running
with a SecurityManager and -illegal-access=deny but granting
|ReflectPermission("supressAccessChecks") |could escape the sandbox[1].
I found a way to escape the sandbox, which relies on the power of the
Lookup returned by privateLookupIn.
As this has been changed, I wonder if this escape was ever intended in
the first place. Are there any resources out there that can help answer
this question?
Thanks,
Johannes
[1]:
https://stackoverflow.com/questions/51712903/is-it-safe-to-grant-untrusted-code-supressaccesschecks-when-illegal-access-de
