RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields
Mark Sheppard
mark.sheppard at oracle.com
Thu Jun 9 14:49:43 UTC 2016
Hi Chris,
thanks for the feedback
yes, that's correct the granting of the all permissions to corba, allows
this solution to work.
Without all permission the RuntimePermission accessDeclaredField is
needed and the doPrivilege is redundant, but
the module-info export is needed.
It is possible to reduce the test to a scenario which uses Test3 and
Test4 classes only, as they emulate those
used in the customer application which triggered the problem.
regards
Mark
On 09/06/2016 13:35, Chris Hegarty wrote:
>> On 8 Jun 2016, at 23:18, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>>
>> Hi
>> please oblige and review the following changes
>> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/
>>
>> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/
>>
>> which address the issue raised in
>> https://bugs.openjdk.java.net/browse/JDK-8146975
>>
>> the type checking in inputClassFields and other places failed to fully allowing for
>> the processing of return ValueTypes, and hence the getDeclaredField fails as
>> "application code" exist on the call stack restricting access. This leads to a security exception,
>> which in turn leads to an IllegalArgumentExcetption, the processing of which failed to allow
>> for a null object value in the stream.
>> This has now been rectified, with the getDeclaredField wrapped in a doPrivileged call.
> This works because the java.corba module is granted all permissions. If this
> was to ever change then I assume it would require RuntimePermission(
> "accessDeclaredMembers”).
>
> The changes look ok to me. Wow, that is some test! I assume it cannot easily
> be reduced.
>
> -Chris.
>
>> regards
>> Mark
More information about the core-libs-dev
mailing list