On Mon, Mar 12, 2012 at 05:14:16PM -0400, Chuck Lever wrote: > IMO, the server should do a comparison of the nfs_client_id4 strings, > and nothing else. We're supposed to return CLID_INUSE when we see a setclientid from a "different" client using the same string, to keep clients from doing mischief with other clients' state (either maliciously or, as in this case, accidentally). "Different" here is defined as "not having the same principal". I know what that means in the krb5 case, but I'm less certain in the auth_sys case. > The client IP addresses are unreliable. Otherwise, > why have an nfs_client_id4 string to begin with? And how could a > multi-homed client ever word? I don't know. Is it expected that such clients would do setclientid's over different interfaces and expect it to work? (I'm trying to remember now how we identify clients for the purposes of NSM. In the auth_sys case maybe the goal should be to keep things working more or less as they did with auth_sys under v2/v3.) > Maybe I don't understand what you mean. > > But, anyway, if the clients are all using the same nfs_client_id4 > string, that's going to cause no end of trouble, since the boot > verifier for each of these clients is bound to be different. When the > server sees a boot verifier change, it will just drop all the client's > state. Each client's SETCLIENTID will trash the state of anything > that came before attached to that nfs_client_id4. That will result in > the clients all constantly trying to recover state. Yes, looks like something like that is happening. This is probably a case of a slightly exotic (and possibly broken in some sense) client network setup--but those may turn out to be more common than we'd like. --b. > I suppose the > server could watch for a boot verifier replay (cel ducks) -- 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
