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
