> On Apr 2, 2019, at 9:33 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
>
> On 4/1/19 11:12 PM, Weijun Wang wrote:
>> I can understand the change in Permissions, but is there any difference in
>> PermissionsHash?
>
> The key and value in the PermissionsHash map is always the same object. This
> fix ensures that is respected, otherwise after deserialization you could have
> a SocketPermission mapped to a FilePermission, for example. Would it be
> better if I added a test for that?
Yes, you are right. I thought the old code can also enforce this relation.
Now for the test, perms.ser is binary and you haven't described how it is
generated.
Thanks,
Max
>
> --Sean
>
>> --Max
>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
>>>
>>> It is currently possible to change the mappings in a serialized
>>> java.security.Permissions object such that they no longer map correctly,
>>> and Permissions.readObject won't detect this.
>>>
>>> This change makes sure that for a deserialized Permissions object, the
>>> permissions are mapped correctly to the class that they belong to. It does
>>> this by calling add() again for each permission in the deserialized
>>> Permissions object. The same technique was applied to a serialized
>>> PermissionsHash object which is used to store Permissions that don't
>>> implement their own PermissionCollection.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637
>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/
>>>
>>> Thanks,
>>> Sean
>>>
