[13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings

[Weijun Wang]

> On Apr 2, 2019, at 9:33 PM, Sean Mullan <sean.mullan at 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.mullan at 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
>>>