SocketPermission's implies() interesting behavior

[Chris Hegarty]

On 21/02/2011 02:36, Charles Lee wrote:
> :
> Thanks Chris. You have answer my first question. I have noticed that IP
> is important when we try to judge the imply. So it comes my other

Yes, IP is very important. SocketPermission tries to resolve hostnames 
to IP before asserting checks.

> questions:
> 1. What if the machine is multihost? Two different domains may have the
> same IP. (localhost.localdomain vs mytest)

SocketPermission star_All = new
SocketPermission("localhost.localdomain", "listen,accept,connect");
SocketPermission www_All = new SocketPermission("mytest",
"listen,accept,connect");
System.out.println(star_All.implies(www_All));

Return is true.

I think this is reasonable, since you explicitly edited /etc/hosts so 
that mytest and localhost.localdomain resolve to the same IP. If you try 
to make a connection to each of these hostnames, then you will actually 
be trying to connect to the same machine.

> 2. What if the domain name can not be got from the dns? (*.blabla.bla vs
> bla.blabla.bla)

I guess since SocketPermissions are typically useful in asserting 
privilege before connecting, then this is not such a common problem. 
Since the host bla.blabla.bla does not resolve you cannot connect to it. 
The java.net, and I believe nio, socket/channel classes try to resolve 
the hostname before asserting privileges, and 
UnknownHostException/UnresolvedAddressException will be thrown at this 
point.

I guess you have seen trustProxy? This was added for situations where 
the user is behind a firewall and deferring all actual connections to a 
proxy. I would have expected that -DtrustProxy=true would cause 
*.blabla.bla to imply bla.blabla.bla, but it does not. Maybe 
inProxyWeTrust() should accept wildcards?

-Chris.