RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

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.

Regards,

Peter.

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.
>
> Roger
>
>
> 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.
>>
>> /Clae
>