RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

[Johannes Kuhn]

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