On 29/04/2021 10:57 pm, Sean Mullan wrote:
On 4/29/21 1:37 AM, Peter Firmstone wrote:
We have our own security manager implementation and policy provider
implementations. Both of these are high performance and non-blocking
and we are able to dynamically grant and revoke some permissions.
While I acknowledge the Java policy implementation has a significant
performance impact, due to blocking permission checks, ours is less
than 1%. Our software doesn't share PermissionCollection instances
among threads, or even have a Permissions cache,
PermissionCollection's are generated for each permission check and
discarded for garbage collection, the Permission object themselves
are cached (after initialization and safe publication), as are the
results of repeated permission checks. We also have our own
Permission implementations.
Yes, you and I had discussions about this several years ago and I
believe I asked if you would be willing to donate these performance
improvements. I can't remember but I think you had interest in doing
that but couldn't make it happen for some reason.
Licensing, parts of the code I could donate as I am the original author,
but other parts were AL 2.0 licensed by others, I think I found some
AL2.0 code in OpenJDK at the time, but I was having trouble getting
clarity around licensing, I don't remember the details but I think I
needed to contact the other authors and have them sign contributor
agreements or rewrite their code.
The two components that caused licensing issues were the policy parser
(although Java has it's own, so not a major issue) and an RFC 3986 URI
implementation which replaced URL, which was heavily utilised, it
normalizes URI for policy implies checks, including RFC 5952 IPv6
address normalization, OS specific file based URI were normalized
dependent on the underlying OS (eg uppercase for Microsoft). Using
Java's URI wasn't an option as it wouldn't normalize appropriately,
while using URL would cause blocking network calls.
It is a strict RFC 3986 implementation, Unicode characters beyond
US-ASCII are escaped, and it utilises bit shift operations during
normalization, it's also immutable and not serializable, so it wasn't a
backward compatible replacement for Java's URI.
The difference between URI and URL use in policy files, was that if two
different domain names resolved to the same IP Address, they implied
each other under a URL ( required blocking network dns calls), while
they didn't imply one another under URI. This had the added benefit of
allowing one domain name to resolve to multiple IP addresses without
having to add multiple IP addresses to policy files, for example
fail-over web server addresses.
Some trivia, I also wrote a URIClassLoader that replaced URLClassLoader,
specifically to override behaviour in SecureClassLoader, where URL's are
used as key's in a cache, again for performance reasons.
Re-implementing RFC 3986 URI functionality was a significant
undertaking, I wasn't familiar with OpenJDK's build system, was busy
with other things so I put it off until later... which hasn't happened
yet lol.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
