SocketPermission's implies() interesting behavior

[Charles Lee]

On 02/21/2011 09:57 PM, Chris Hegarty wrote:
>
>
> 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?
Yes, I hope so. Maybe in the doc, there should be somewhere mention these.

>
> -Chris.