On Wed, Feb 13, 2013 at 8:55 AM, Martijn de Gouw
<martijn.de.gouw@xxxxxxxxxxx> wrote:
>
> On 02/01/2013 06:51 AM, Steve French wrote:
>>
>> I would like to trace this to check - I will try to resetup some DFS
>> share referrals tomorrow
>
>
> Did you manage to trace to check this?
Yes - I traced various configurations using ntlm (need to retry with
ntlmssp) to Samba. NTLM mounts do not appear to need a change.
1) first server had signing disabled (which brings up the obvious
question, why does Samba disable signing for cifs share exports by
default?) - failed as expected
2) first server had signing enabled, second server disabled and force
signing by specifying sec=ntlmi on mount - mount worked, but cd to DFS
referral failed as expected (since second server didn't support
signing and we specified it on the mount)
3) and the same configuration, with the mount not requesting signing -
upgraded to signing automatically on the connection (DFS referral) to
the second server. Worked as expected.
Although your patch would work, I am curious why the kerberos
connection does not do the same thing as ntlm but that will be a
little trickier to setup (and I will try it tomorrow).
>> On Thu, Jan 31, 2013 at 8:31 AM, Martijn de Gouw
>> <martijn.de.gouw@xxxxxxxxxxx> wrote:
>>>
>>>
>>> On 01/31/2013 05:53 AM, Steve French wrote:
>>>>
>>>>
>>>> On Wed, Oct 24, 2012 at 4:45 AM, Martijn de Gouw
>>>> <martijn.de.gouw@xxxxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>> Setting this secFlg allows usage of dfs where some servers require
>>>>> signing and others don't.
>>>>>
>>>>> Signed-off-by: Martijn de Gouw <martijn.de.gouw@xxxxxxxxxxx>
>>>>> ---
>>>>> :100644 100644 b39bb4a... 4da9dd3... M fs/cifs/connect.c
>>>>> fs/cifs/connect.c | 2 +-
>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>>>>> index b39bb4a..4da9dd3 100644
>>>>> --- a/fs/cifs/connect.c
>>>>> +++ b/fs/cifs/connect.c
>>>>> @@ -994,7 +994,7 @@ static int cifs_parse_security_flavors(char
>>>>> *value,
>>>>>
>>>>> switch (match_token(value, cifs_secflavor_tokens, args)) {
>>>>> case Opt_sec_krb5:
>>>>> - vol->secFlg |= CIFSSEC_MAY_KRB5;
>>>>> + vol->secFlg |= CIFSSEC_MAY_KRB5 | CIFSSEC_MAY_SIGN;
>>>>> break;
>>>>> case Opt_sec_krb5i:
>>>>> vol->secFlg |= CIFSSEC_MAY_KRB5 | CIFSSEC_MUST_SIGN;
>>>>
>>>>
>>>>
>>>> Wouldn't this same problem occur if ntlm or ntlmv2 were authenticated
>>>> and a dfs referral sent us to a server which required signing - if
>>>> that is the case then it is not just Opt_sec_krb5 which needs to OR in
>>>> CIFSSEC_MAY_SIGN but also Opt_sec_ntlmssp and Opt_ntlm (also why do we
>>>> call this Opt_ntlm instead of Opt_sec_ntlm like the other 10?) and
>>>> Opt_sec_ntlmv2?
>>>>
>>>>
>>>
>>> Using sec=ntlm on the same dfs I did not see this problem. So I guess
>>> not.
>>>
>>>
>>> --
>>> Martijn de Gouw
>>> Engineer
>>> Prodrive B.V.
>>> Mobile: +31 63 17 76 161
>>> Phone: +31 40 26 76 200
>>
>>
>>
>>
>>
>> --
>> Thanks,
>>
>> Steve
>>
>
> Regards,
> Martijn
>
> --
> Martijn de Gouw
> Engineer
> Prodrive B.V.
> Mobile: +31 63 17 76 161
> Phone: +31 40 26 76 200
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
