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.



On 15/08/2019 8:56 PM, Alan Bateman wrote:
On 15/08/2019 11:03, Claes Redestad wrote:

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.


Reply via email to