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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
