Re: [PATCH 09/11] cifs: allow mixed secTypes on a socket
Jeff Layton <[email protected]> Fri, 7 May 2010 14:45:24 +0200
| Newsgroups | gmane.linux.file-systems.cifs |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 7 May 2010 06:56:05 -0500 Steve French <[email protected]> wrote: > On 5/7/10, Jeff Layton <[email protected]> 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 <[email protected]>