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

[Shirish Pargaonkar]

On Fri, May 7, 2010 at 2:51 AM, Steve French <smfrench at gmail.com> wrote:
> On Fri, May 7, 2010 at 2:31 AM, Jeff Layton <jlayton at redhat.com> wrote:
>>> > @@ -978,42 +978,39 @@ cifs_parse_mount_options(char *options, const char
>>> > *devname,
>>> >                                cERROR(1, "no security value specified");
>>> >                                continue;
>>> >                        } else if (strnicmp(value, "krb5i", 5) == 0) {
>>> > -                               vol->secFlg |= CIFSSEC_MAY_KRB5 |
>>> > -                                       CIFSSEC_MUST_SIGN;
>>> > +                               vol->sectype = Kerberos;
>>> > +                               vol->sign = true;
>>> >                        } else if (strnicmp(value, "krb5p", 5) == 0) {
>>> > -                               /* vol->secFlg |= CIFSSEC_MUST_SEAL |
>>> > -                                       CIFSSEC_MAY_KRB5; */
>>> >                                cERROR(1, "Krb5 cifs privacy not
>>> > supported");
>>> >                                return 1;
>>> >                        } else if (strnicmp(value, "krb5", 4) == 0) {
>>> > -                               vol->secFlg |= CIFSSEC_MAY_KRB5;
>>> > +                               vol->sectype = Kerberos;
>>> >
>>>
>>>
>>> Doesn't this change behavior a lot - user can no longer pass in a list of
>>> more than one acceptable security options as before (e.g. sec=krb5,
>>> sec=ntlmv2i)
>>> and can only specify one (but doesn't know ahead of time which the server
>>> supports).
>>>
>>> Also curious if it changed how plaintext was handled (if build with weak
>>> password support allowed, which I don't want to encourage) - IIRC we sent
>>> this via the older (LANMAN only) style session setup.
>>>
>>>
>>
>> It does change that behavior. I didn't realize that was a use case we
>> were interested in supporting.
>>
>> Note that the existing code:
>>
>> 1) doesn't take the order of sec= options into account to indicate the
>> preference (this one will, with the well-established behavior that last
>> option specified wins)
>>
>> 2) doesn't try multiple auth types in turn. It's going to pick one and
>> go with it.
>>
>> If it is important to allow specification of multiple sec= options,
>> could you clarify what should the behavior be when someone does this
>
> 1) If no sec options specified on mount, it chooses among the available
> mechanisms (configurable globally in /proc/fs/cifs - a distro could
> populate this pseudofile at boot time from a configuration file, if
> they want to
> restrict or expand the available mechanisms) and picks from among
> those the server supports.
>
> 2) If one sec option is specified on mount, that mechanism is used
> if the server supports it, otherwise fails
>
> 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"
>
> 2) If sec options
>
>
>
> --
> Thanks,
>
> Steve
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

Should cifs consider at all security mechanisms a server
provides/supports in neg prot response?
In case of this Win7, I see snmpv2-smi and ntlmssp but no kerberos e.g.