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?
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
Regards,
Martijn
--
Martijn de Gouw
Engineer
Prodrive B.V.
Mobile: +31 63 17 76 161
Phone: +31 40 26 76 200
--
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
