I would like to trace this to check - I will try to resetup some DFS share referrals tomorrow
On Thu, Jan 31, 2013 at 8:31 AM, Martijn de Gouw <[email protected]> wrote: > > On 01/31/2013 05:53 AM, Steve French wrote: >> >> On Wed, Oct 24, 2012 at 4:45 AM, Martijn de Gouw >> <[email protected]> wrote: >>> >>> Setting this secFlg allows usage of dfs where some servers require >>> signing and others don't. >>> >>> Signed-off-by: Martijn de Gouw <[email protected]> >>> --- >>> :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 -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
