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