On Wed, 24 Oct 2012 17:03:10 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Oct 24, 2012 at 10:30:15AM -0400, Jeff Layton wrote: > > Add a new client tracker upcall type that uses call_usermodehelper to > > call out to a program. This seems to be the preferred method of > > calling out to usermode these days for seldom-called upcalls. It's > > simple and doesn't require a running daemon, so it should "just work" > > as long as the binary is installed. > > > > The client tracking exit operation is also changed to check for a > > NULL pointer before running. The UMH upcall doesn't need to do anything > > at module teardown time. > > That does look relatively simple, neat. > > One complaint, a preexisting problem, really: we're passing up the md5 > of the client owner name. We should pass up the original client name, > instead, and make that what we store internally in cl_name. If nothing > else, it could be useful for debugging. > > Those names can be up to 1K, though--is that a problem? > We do pass the original client name (hex-encoded) as the second argument on some of the commands. If you look in the database, here's what a row of the clients table looks like: sqlite> select * from clients; 2001:470:8:d63:3a60:77ff:fe93:a95d/2001:470:8:d63:5054:ff:fe9b:3976 tcp|1351162903 The part before the '|' is the client name blob, and the part after is the epoch timestamp for it. We also pass the md5-hashed directory pathname as $NFSDCLTRACK_LEGACY_RECDIR in "check", and the $NFSDCLTRACK_LEGACY_TOPDIR in "gracedone". My rationale for passing that info on rather than just having userspace find/calculate it follows... > I don't understand why the kernel needs to be involved here--can't > userspace find the old directory on its own? My original thinking was to do all of this in userspace and not have the kernel pass any extra info, but was waved off by several folks who do userspace development, mostly for reason #3 below. We could, in principle, do all of the legacy migration in userland. There are a few reasons to have the kernel involved however: 1) this is not using the keys API, so we have no way to change the arguments passed to the program without kernel involvement. So, we'd probably need a kernel parm to disable the legacy transition mode anyway. I suppose that we could make the kernel call a wrapper script that in turn sources a file under /etc/sysconfig or /etc/default that has extra command-line arguments. That seems like more trouble than it's worth, but we could consider doing that if you think it's desirable. 2) I think having the kernel pass this info is at least slightly better for performance. We eliminate the need to open /proc/fs/nfsd/nfsv4recoverydir at all, and go straight to where we need to go. We also eliminate the need to re-calculate the md5 hash in userspace this way. 3) finally, we eliminate the need to pull in a md5 hashing routine into the userland program. My reasoning for this is somewhat selfish... The govt. FIPS certification states that you can only use certain crypto algorithms in certain libraries. MD5 is not on that list. Even if it were, you'd need to pull in library support to handle it -- you can't just roll your own routine to do crypto without running afoul of the FIPS "enforcers". We'd have to add a dependency on something like libnss or openssl (and I know how steved feels about extra nfs-utils dependencies). When you boot in "FIPS mode", non-approved crypto code must be disabled (unrunnable). The kernel already has some code to handle this. I imagine that NFSv4 serving won't work at all in FIPS mode due to this fact since SETCLIENTID/EXCHANGE_ID ops will fail (ouch). Now, we could claim that no one will run this program unless they can use md5 hashes anyway, or try to get an exception for using md5 here since it's not really for security purposes, but it's giant PITA either way. If we have the kernel just pass this info on, then we can sidestep that issue altogether. Note that I'm not married to this method of doing the transition mode. If the consensus is to do it all in userland, I can do that. I think this way is probably better though. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
