Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack
peter.levart at gmail.com
Thu Mar 28 15:46:00 UTC 2019
On 3/28/19 4:08 PM, Alan Bateman wrote:
> On 28/03/2019 14:48, Peter Levart wrote:
>> In addition, if access from null caller is granted and it is
>> performed to a member in a "concealed" package, there's no warning
> The proposed check is that the package is exported unconditionally so
> it will fail, no warning needed. I think that is okay. I could imagine
> someone trying to argue that they run with `--add-exports
> java.base/<concealed-package>=ALL-UNNAMED` and they expect their JNI
> code to be able to reflect on the public members of public classes in
> that package but it hardly seems wroth it as JNI doesn't do access
> checks so it's pointless writing JNI code to use reflection.
Right, and it would require deep changes to
AccessibleObject#logIfExportedForIllegalAccess too, since it assumes the
presence of non-null caller...
Nevertheless the access checking logic could be encapsulated entirely in
the Reflection class (for null caller too) and then in AccessibleObject,
the logIfExportedForIllegalAccess call just skipped for null caller...
Else the logic is scattered between two classes and would have to be
repeated for other similar cases.
Reflection.verifyMemberAccess() is called not only from
AccessibleObject.slowVerifyAccess() but from elsewhere too.
For example, from ReflectUtil.ensureMemberAccess which is used in @CS
AtomicXxxFieldUpdater(s), or from @CS java.util.ServiceLoader.load...
By encapsulating it in the common Reflection.verifyMemberAccess()
method, all those usages get handled at the same time.
More information about the core-libs-dev