Bug 6787 - can't mount cifs w/ntlmv2 from sparc linux client
Summary: can't mount cifs w/ntlmv2 from sparc linux client
Status: CLOSED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.4
Hardware: Sparc Linux
: P3 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-07 15:11 UTC by Nick Leippe
Modified: 2016-02-25 18:24 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Leippe 2009-10-07 15:11:15 UTC
gentoo linux, kernel independent (have tested 2.2x - 2.31)

mount-cifs versions up to and including 3.0.30

on x86, the following works:

mount -t cifs //<ip addr>/wipelog /mnt/test -o \
username=<un>,domain=<d>,sec=ntlmv2
Password: <pwd>
# works

while the exact same command, on the exact same network from a sparc64 gentoo linux machine, same versions of kernel and mount-cifs package produces:

mount -t cifs //<ip addr>/wipelog /mnt/test -o \
username=<un>,domain=<d>,sec=ntlmv2
Password: <pwd>
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Backing the server down to ntlm (v1) works from both x86 clients, but v2 does not.
Comment 1 Nick Leippe 2009-10-07 15:12:36 UTC
typo on kernel versions tested--meant kernel versions 2.6.2x - 2.6.31
Comment 2 Volker Lendecke 2009-11-30 16:14:28 UTC
Jeff, I think this is yours :-)

Volker
Comment 3 Jeff Layton 2009-11-30 20:54:03 UTC
Steve, any thoughts on this? Sounds like an endianness problem, but I'm not that familiar with the ntlmv2 code.

I see this in CalcNTLMv2_response():

        memcpy(v2_session_response + 8, ses->server->cryptKey, 8);

...which looks like it probably needs to be endian converted, no? I'm guessing there may be other places as well.
Comment 4 Jeff Layton 2009-11-30 20:59:34 UTC
One thing that might not hurt is a capture of the traffic between client and server while reproducing this. That should tell us on what call this is occurring. It's probably during session setup, but it wouldn't hurt to be sure. Info on how to do that is here:

http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
Comment 5 Jeff Layton 2010-01-25 11:08:12 UTC
Reassigning to Steve since he understands NTLMv2 much better than I...
Comment 6 Karolin Seeger 2010-02-08 03:28:47 UTC
Is this one really a blocker for 3.5.0?
Comment 7 Jeff Layton 2010-02-08 05:50:23 UTC
Almost certainly not. mount.cifs just hands the plaintext password off to the kernel. The kernel does all of the hashing and assembly of packets for NTLMv2. If there's a problem in this area, it's almost certainly in the kernel and not in samba or any of the userspace code.

Reducing severity from "blocker" to "normal".
Comment 8 Jeff Layton 2012-05-05 11:15:02 UTC
Does this work better with a more recent kernel? The NTLMv2 auth code was
overhauled within the last year or so, and I suspect that this bug was
fixed in the process.
Comment 9 Steve French 2014-10-19 00:21:00 UTC
Assuming that this is fixed with the NTLM auth overhaul.  Looked like an old endianness issue long fixed.