[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070504155710.GB18522@dantu.rdu.redhat.com>
Date: Fri, 4 May 2007 11:57:11 -0400
From: Jeff Layton <jlayton@...hat.com>
To: "Steve French (smfltc)" <smfltc@...ibm.com>
Cc: linux-cifs-client@...ts.samba.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Jeff Layton <jlayton@...hat.com>, hch@...radead.org
Subject: Re: [PATCH] CIFS: make sec=none force an anonymous mount
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists