Simo Sorce wrote: No this is not what I am saying. The client uses the fully qualified name at the mount command but due to the use of a PTR lookup it is fooled into acquiring a ticket for the wrong server which will then happily allow you to connect. Currently: The mount command tells the kernel both the server name 'secure.server.name' and it's IP address 1.2.3.4 however rpc.gssd currently completely ignored the server name passed in by the mount command (see the 'dummy' variable) and instead uses the ip address to do a reverse lookup. PTR lookup of 1.2.3.4 --- MITM ---> public.server.com Then it uses the retrieved name (public..) to construct the GSSAPI name it wants to connect to, the result is that the name nfs@xxxxxxxxxxxxxxxxxx is constructed instead of the requested nfs@xxxxxxxxxxxxxxxxx that should be requested. So the client does ask for the right server but can be easily tricked into connecting to another one. Kerberos itself *is* correctly identifying the server, it's rpc.gssd that opened it'sself to being fooled before involving Kerberos. Ok, I think I understand now. I suggest adding some of that text into the commit log. And stop using the term "mitm". A mitm attack is used to convince both ends of a connection that they are talking to each other. DNS is not a mutually authenticated exchange. This discussion is making me nervous. It makes me think no one has thought through the use of kerberos to authenticate nfs connections on linux. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
