RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

Hello Alan,

This is related to URL and CodeSource and might be worth making a note 
of for future reference.

Our software uses delayed dynamically assigned permissions via a policy 
provider, but for privileged domains that have AllPermission we make 
sure to assign this up front (We also utilise an RFC3986URIClassLoader 
and override CodeSource, so we're using our RFC3986 compliant URI 
instead of URL).  The former because we dynamically download 
CodeSource's and there's no way of predicting up front which will be 
downloaded and the latter as a performance optimisation of ProtectionDomain.

So we have a RFC3986 URI implementation, similar to Java's URI, it is 
not Serializable for security reasons.

In addition to RFC3896 normalization, we have also recently added the 
ability to normalize IPv6 address conformant to "RFC 5952 A 
Recommendation for IPv6 Address Text Representation."   The class also 
normalizes file system paths in a platform dependant manner, eg Upper 
Case for MS Windows, but not Unix.

We have a URI::implies method that is similar to CodeSource::implies, 
with matching rules.

We do this to avoid DNS calls or accessing the file system unnecessarily.

Also, to avoid synchronization / locking overhead of 
PermissionCollection's and Permissions, we have a Policy provider that 
generates a thread confined Permissions and PermissionCollection 
instances on demand, allowing them to be garbage collected as soon as 
the implies call returns (Permission objects are initialized up front 
and effectively immutable and cached) a PermissionComparator also 
arranges the Permissions in an order that improves performance wen 
creating PermissionCollection instances.

Our Security overhead is less than 1% as a result and the delays and 
blocking we had due to DNS calls have been eliminated.

Regards,

Peter.

On 15/08/2019 8:56 PM, Alan Bateman wrote:
> On 15/08/2019 11:03, Claes Redestad wrote:
>> Hi,
>>
>> by resolving permissions for code source URLs lazily, we can reduce
>> early class loading during bootstrap, which improves footprint, startup
>> and reduces the typical bootstrap dependency graph.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8229773
>> Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/
>>
>> :
> I think the approach is okay as URL::openConnection doesn't actually 
> open the connection to the resource and the creation of the 
> URLStreamdHandler shouldn't depend on permissions granted to the 
> caller. If a handler needs permissions when creating the URLConnection 
> then it should do so in a privileged block. I think it would be a bit 
> cleaner if the supporting class would lazily add the permissions for a 
> CodeSource to the collection. That is, create it with a permissions 
> collection and code source rather than a URL to match 
> SecureClassLoader::getPermissions. You could potentially use it in 
> URLClassLoader getPermission(CodeSource) method too.
>
> In System.setSecurityManager then you might need 
> DefaultFileSystemProvider.theFileSystem() to ensure that the default 
> file system is fully initialized before setting the SM.
>
> A minor nit this adds a spurious import BuiltinClassLoader. Also it 
> can import the sun.security.uti class to be consistent with the 
> existing code.
>
> -Alan
>
>
>