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

[Sundararajan Athijegannathan]

Looks good.

-Sundar

On 28/03/19, 4:47 AM, Mandy Chung wrote:
> This is to fix a regression introduced in JDK 12 by JDK-8206240.
> This impacts only native application that creates JVM via JNI
> and also invokes Field::getField (or other reflection API) via
> JNI that triggers reflection access check against the caller class.
> The regression happens only when there is no caller frame, i.e.
> when a native thread attaches to JVM e.g. custom launcher.
>
> It's unclear why the native code invokes Field::getField via JNI
> to get the value of `java.lang.Integer::TYPE`.  Alternatively it could
> call GetFieldID to get jfieldID of that field and then GetObjectField
> if this has to be done in JNI (perhaps bypass encapsulation?).
>
> There is no clear semantics what reflection should behave when there
> is no caller frame.   Previously, JNI call to access 
> `java.lang.Integer.TYPE`
> field happens to work since it is called very early at runtime and
> AccessibleObject::cache is null and happens that cache == caller == null.
>
> 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.
>
> If a native thread attaches to the VM and attempts to access a non-public
> member or a public member in a non-exported type e.g. 
> jdk.internal.misc.Unsafe,
> it will throw IAE whereas the access check succeeds in JDK 11. It is
> illegal to access a non-exported type.   I think the compatibility risk
> should be low as this only happens to a native code creating its VM and
> calling reflection to access a member in a non-exported type. There is
> no change to the behavior of JNI GetFieldID and GetObjectField.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.00/
>
> I will create a CSR.
>
> Thanks
> Mandy