Simon IJskes - QCG wrote:
On 31-12-11 14:33, Peter wrote:
Any thoughts or experience replacing java classes using the
-Xbootclasspath option?
This means creating a new java.net.SocketPermission, completely
replacing it and SocketPermissionCollection in the jvm libraries.
My gut feeling tells me, do not go there. Is this because of the
lookup problem?
Partly motivated by that and partly by the history of deployment issues
with DNS.
We can assume river is only used on LAN's and when we use it on the
internet, do we still need the socketpermission as a safety measure?
Unfortunately more so, since the internet would be accessed from the
LAN, the SocketPermission would determine if a user and proxy was
allowed / trusted to connect to the LAN (if the proxy is from the
internet), apart from the default return address granted to the proxy by
default (DownloadPermission granted to a codebase signer is the only way
to stop it). A LAN may contain hosts who's only protection against
attack is the firewall.
If a replacement implementation of SocketPermission behaved as expected
by default, we could provide a configuration property that says don't do
reverse dns lookups or don't perform dns lookup at all when resolving
SocketPermission.
If there are no dns lookups the administrator (who sets the property)
then know's that the policy files must have IP addresses as well as
domain names for SocketPermission's since one wouldn't imply or equal
the other.
Generally dns lookup works, it's the reverse lookup's that cause
problems, when the DNS server doesn't support it or is misconfigured.
Still, Dan might be right, the solution probably is to just use another
provider that detects a misconfigured environment and responds
accordingly. In that case a SocketPermission still won't imply IP
addresses to domain names, but it might handle the situation in a much
more timely manner. This would behave identically to a
reimplementation, albeit with a little less thread safety and broken
behaviour of equals and hashCode, but I'm successfully getting around
that using a Comparator and being selective about the Collections used
to store Permissions.
The dns provider probably needs it's own background thread, so it can
perform housekeeping and monitoring of the local dns environment, rather
than wait for a request thread before doing so. www.dnsjava.org is
probably a good starting point.
Cheers,
Peter.
