Hi Sean,
Typically, fixed serialization streams are encoded in the source
as byte arrays. That keeps binary content out of the repo
and provides a place for the comments.
Roger
On 04/02/2019 09:50 AM, Sean Mullan wrote:
On 4/2/19 9:44 AM, Weijun Wang wrote:
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.
I just hacked Permissions.writeObject to switch the mappings. That was
a lot easier than trying to write my own serialization code. I will
add some comments in the test explaining how I did that and what is in
perms.ser.
--Sean
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