Hi Roger,

+1 for writeReplace

Personally I'd like to see some security classes break backward compatibility and remove support for serialization as it allows someone to get references to internal objects, especially since these classes are cached by the JVM. Which makes PermissionCollection.setReadOnly() very easy to bypass, by adding permissions to internal collections once you have a reference to them.

Does anyone have any use cases for serializing these objects?

These objects are easy to re-create by sending or recieving and parsing strings, because they are built from text based policy files, and when you do that, you are validating input, so I never did fully understand why they were made serializable.



On 16/08/2019 12:54 AM, Roger Riggs wrote:
Hi Claes,

I would recommend using writeReplace to serialize the PermissionCollection so the serialized form does not change. Though these are unlikely to be serialized, it will be less likely to trigger some interoperability issue between different version. It may need to be documented that serializing/deserializing does not retain the lazyness.


On 8/15/19 10:30 AM, Claes Redestad wrote:
Hi Sean,

On 2019-08-15 15:07, Sean Mullan wrote:
Hi Claes,

I already reviewed an earlier version of this and this is pretty similar. I did have a question about whether the default serialization was ok - did you look into that more?

ah, yes.. all the constituents are serializable (whether we wrap the
CodeSource or its URL) so the new Lazy..Collection should be too. I was
entertaining the idea that we could writeReplace the lazy collection
with a PermissionCollection to avoid polluting serialization use cases
with new type, but couldn't think of any real upside to that.


Reply via email to