RFR: 8229773: Resolve permissions for code source URLs lazily

[Sean Mullan]

On 8/15/19 8:18 PM, Peter Firmstone wrote:
> 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.

This is briefly explained on page 61 in the "Inside Java 2 Platform 
Security" book [1]:

"The Permission class implements two interfaces: java.security.Guard and 
java.io.Serializable. For the latter, the intention is that Permission 
objects may be transported to remote machines, such as via Remote Method 
Invocation (RMI), and thus a Serializable representation is useful."

The Permission class was introduced in Java SE 1.2 so there were 
different motivations back then :)

--Sean

[1] https://www.oracle.com/technetwork/java/javaee/index-141918.html