[linux-cifs-client] [PATCH 09/11] cifs: allow mixed secTypes on a socket

[Jeff Layton]

On Fri, 7 May 2010 06:56:05 -0500
Steve French <smfrench at gmail.com> wrote:

> On 5/7/10, Jeff Layton <jlayton at samba.org> wrote:
> >> > 3) If more than one sec option is specified, the behavior should
> >> > be similar to temporarily setting the available mechanisms
> >> > in /proc/fs/cifs  (cifs.ko picks among those based on
> >> > what the server would support).   General idea with specifying
> >> > multiple sec options - the user says which mechanisms
> >> > are acceptable to it, and as long as the server supports them,
> >> > the user lets cifs.ko decide which is "best"
> >> >
> >>
> >> This tosses out that behavior. Do you feel it's important to preserve
> >> it somehow?
> 
> Yes - being able to specify the only acceptable mechanisms
> (e.g. sec=ntlmv2i,sec=krb5) is required in various cases.
> Alternatively you have to flip the global security flags
> temporarily which is more awkward and even
> dangerous, if different mounts are issued close in time, or
> worse, you have to retry the mounts multiple times with different
> sec= flags each time (which is hard to do with automated
> mounting via fstab).
> 
> >
> > FWIW, I'll also note that the sec= documentation is pretty sparse:
> >
> >        sec=
> >            Security mode. Allowed values are: (blah)
> >
> > ...so I'm not sure that we have any sort of "social contract" to
> > preserve the existing behavior of multiple sec= options.
> Yep.  I agree that we need to add more information to the man page,
> and the Users Guide is long overdue for an update.
> 
> Since this topic (specifying multiple sec= on mount) came up
> when this was originally added/discussed and there is a logical
> reason for it (I might use this when not on a private network, talking
> to a server which I don't know the user configuration for) - we
> should probably preserve that behavior.
> 

Ok, that'll mean a major rewrite of that patch and the general
approach. I'll see what can be done.

-- 
Jeff Layton <jlayton at samba.org>