On Fri, May 04, 2007 at 10:26:29AM -0500, Steve French (smfltc) wrote: > Jeff Layton wrote: > >We had a customer report that attempting to make CIFS mount with a null > >username (i.e. doing an anonymous mount) doesn't work. Looking through the > >code, it looks like CIFS expects a NULL username from userspace in order > >to trigger an anonymous mount. The mount.cifs code doesn't seem to ever > >pass a null username to the kernel, however. > Yes - cifs kernel code expects a NULL username (e.g. "username=") if > you really don't want to pass the default username of the uid of > the current process and you don't set the username explicitly > (e.g. in a credential file or mount parameter). > > Samba userspace tools (and smbfs) handled this by first trying to > setup the SMB session using the default user, and if that fails > with access denied then retrying sessionsetup with a null username > string. This would be easy to change in mount.cifs (ie as long > as username was not explicitly passed on mount then if mount fails > with access denied simply add a retry with "username="). This was > discussed at SambaXP. >
Does this mean you're NAK'ing this patch in favor of a userspace fix? My perspective is that if someone explicitly requests sec=none, then we ought to do an anonymous mount regardless of how the username is set. Would you agree that that behavior is what you would want? > > Christoph Hellwig wrote: > >Looks useful. In case you have some spare time at your hand it would > >be really nice to convert cifs option parsing to the lib/parser.c code > >and move all validation of the arguments into one place, so it's easily > >understanable and better to maintain. > > Yes - that would be excellent. The parse_mount_options badly needs to > be rewritten now that the number of mount options needed has grown. > This is something Alex Bokovoy and I discussed last week at SambaXP > for both the kernel code and the user space mount.cifs code. > Alex had volunteered to rewrite the user space cifs mount option > parsing code (and also change to use the safer talloc library) > Definitely, though that sounds like a big project and I don't have the time to tackle it at the moment :-) Thanks, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/