RFR: 8229773: Resolve permissions for code source URLs lazily
peter.firmstone at zeus.net.au
Thu Aug 15 23:39:24 UTC 2019
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.
More information about the core-libs-dev