From: "Steve French (smfltc)" <smfltc@us.ibm.com>
To: linux-cifs-client@lists.samba.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Jeff Layton <jlayton@redhat.com>,
hch@infradead.org
Subject: Re: [PATCH] CIFS: make sec=none force an anonymous mount
Date: Fri, 04 May 2007 10:26:29 -0500 [thread overview]
Message-ID: <463B50A5.3070500@us.ibm.com> (raw)
In-Reply-To: <20070504024910.CE97B1638AF@lists.samba.org>
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.
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)
next parent reply other threads:[~2007-05-04 15:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070504024910.CE97B1638AF@lists.samba.org>
2007-05-04 15:26 ` Steve French (smfltc) [this message]
2007-05-04 15:57 ` [PATCH] CIFS: make sec=none force an anonymous mount Jeff Layton
2007-05-04 16:41 ` Steve French (smfltc)
[not found] ` <OFEFD715DD.89A7A57F-ON872572D2.003A0BCE-862572D2.003AC6CA@us.ibm.com>
2007-05-05 12:03 ` [linux-cifs-client] " Jeff Layton
2007-05-05 20:47 ` Steve French (smfltc)
2007-05-03 18:32 Jeff Layton
2007-05-03 18:43 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=463B50A5.3070500@us.ibm.com \
--to=smfltc@us.ibm.com \
--cc=hch@infradead.org \
--cc=jlayton@redhat.com \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox