> > > But, I don't know, I'm frankly confused about our security design for > > the NFSv4 state. > > > > When we insist on krb5 (and checked the server name correctly), and > > failed without it, then I feel like I understand what we're doing. Once > > we start trying it and then falling back (as I understand happens for > > the krb5 state in the auth_sys case) I get confused. > > Now you have me confused. I’m aware that we call nfs_create_rpc_client() with a krb5i argument and then fall back to auth_sys if the RPC layer says that we don’t have a running gss daemon or that we can’t load the rpcsec_gss_krb5 module. I’m not aware of us falling back if rpc.gssd is running and tells us that security negotiation failed; we should be returning a mount error in that case. Oh, good, that sounds fine--I'd forgotten it worked that way. So the problem occurs just because gssd and/or the kerberos libraries are allowing us to establish state using a different name and then we're not accepting it on the return. So: On Tue, Apr 08, 2014 at 12:22:51PM -0400, Trond Myklebust wrote: > How is it not better just to rip out that hostname comparison in the > back channel? Rip it out entirely? At that point anyone who can get a credential in the right realm can send a recall. RFC made this requirement to prevent that. But we've already decided we don't care about that in the 4.1 case, so, hey, maybe. I guess it wouldn't bother me. --b. -- 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
