[linux-cifs-client] Re: [PATCH] CIFS: make sec=none force an anonymous mount

[Jeff Layton]

> Your patch is probably ok to add, although I would like to see if any of 
> the other Samba team
> had thoughts on this, as "null user" sessions are a fairly obscure part 
> of the protocol.  But
> even with the kernel change, mount.cifs also should change for a loosely 
> related case that of
>    1) sec=none is not specified by the user
>    2) but username also is not specified explicitly
> For that case we need to retry on access denied as if it were a request 
> for a "null user" mount
> ie send sec=none (or equivalently username=) the 2nd time.  This gets 
> more complicated
> since mount.cifs also has to retry on a couple of other cases (e.g. when 
> the server does
> not support port 445 but does not take the standard server string 
> "*SMBSERVER"
> on the RFC1001 called name).
> 

Yep, I had a look at what it would take to fix this up in userspace. I didn't
spend much time on it, but it looks like we may have to rejigger mount.cifs a
bit for this sort of thing. This starts to get complex because you essentially
have some options that are overriding other options. So you end up with one of:

1) doing option parsing in several passes so you can make sure that certain
   options are parsed before others
2) copying some of the options to a buffer (or more than one) and allowing
   some options to overwrite that buffer

...or some other scheme entirely. Right now we parse an option and then append
it to a string that gets passed to the kernel. Maybe what's best is to do
the option parsing in one pass and have that set a bunch of variables, and then
build the kernel option string based on the contents of those vars. That
would probably make it easier to handle retries as well...

> If there are no objections from any of the other Samba guys I will take 
> your patch which has
> the effect of treating "sec=none" as meaning "ingore any userid if 
> specified, and set the username to null
> on the session setup").   That is consistent with what we documented.
> 

Excellent. Thanks!

-- Jeff