Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

Mandy Chung mandy.chung at oracle.com
Thu Mar 28 15:44:51 UTC 2019



On 3/28/19 1:40 AM, Alan Bateman wrote:
> On 27/03/2019 23:17, Mandy Chung wrote:
>> :
>>
>> The proposed fix is to perform proper access check.  When there is no
>> caller frame, it only allows to access to public members of a public 
>> type
>> in an unconditional exported API package.
>>
> The approach seems reasonable to me and we should, at some point, try 
> to align the other @CS methods with this behavior. As Mandy knows, 
> this is unspecified behavior and we aren't consistent in the JDK on 
> how to handle "no caller frame" case. Some @CS methods will throw NPE 
> if invoked directly, others detect the caller is null and throw or 
> treat it as Object.class.
>

Yup and tracked by JDK-8177155.  I hope to look into a different way to 
reliably bind the caller to @CSM.

> In the patch, shouldn't slowVerifyAccess check that memberClass is 
> public?

Good catch.   Will fix it.

Mandy


More information about the core-libs-dev mailing list