On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote: > On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote: >> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote: >>> Currently the kernel's MNT client always uses AUTH_UNIX if no "sec=" >>> mount option was specified. In the interest of conforming more >>> closely to RFC 2623, teach the MNT client to use the first flavor on >>> the server's returned authflavor list instead of AUTH_UNIX, if "sec=" >>> was not specified. >>> >>> When the user does not specify "sec=" : >>> >>> o For NFSv2 and NFSv4: the default is always AUTH_UNIX (unchanged). >>> >>> o For NFSv3: if the server does not return an auth flavor list, use >>> AUTH_UNIX by default; if the server does return a list, use the >>> first entry on the list by default. >> >> Sounds good, but also: >> >> 1. Even when sec= is provided, we should probably still check >> the passed-in security against the server-returned list. >> (Otherwise AUTH_NULL mounts will almost *always* succeed, even >> when no subsequent file operation would, thanks to the >> allow-AUTH_NULL-on-mount behavior recommended by rfc 2523). >> http://marc.info/?l=linux-nfs&m=125088837303339&w=2 >> >> 2. In the absence of sec=, we should probably *not* choose >> AUTH_NULL. (All mountd's before 1.1.3 list AUTH_NULL first on >> the returned list, so users with older servers may wonder why a >> client upgrade is making files they create suddenly be owned by >> nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2 >> >> 3. As a special exception, we should probably allow an explicit >> "sec=null" to override #1 above, since ommission of AUTH_NULL >> from post-1.1.3 mountd returns will make it otherwise impossible >> to mount with AUTH_NULL. >> http://marc.info/?l=linux-nfs&m=125113569524411&w=2 >> >> Oops, my bad: I see now from the code that you did actually do #1, you >> just didn't mention it above. OK! >> >> I don't see #2 or #3, though maybe they're already handled >> somewhere.... > > No, not in the kernel's MNT client. #3 seems like a server bug to me, > though. Alas, it's apparently a workaround for a client bug: see the url referenced after #3. (But I don't know what client versions that bug was in. If someone investigated and found they weren't widely distributed, I'd take a patch to remove the workaround.) --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
