From: Steven French <sfrench@samba.org>
To: Paulo Alcantara <pc@cjr.nz>, Byron Stanoszek <gandalf@winds.org>
Cc: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: CIFS regression mounting vers=1.0 NTLMSSP when hostname is too long
Date: Wed, 4 May 2022 00:43:42 -0500 [thread overview]
Message-ID: <7dc6c729-73cd-74be-eec7-ac4a0013f60f@samba.org> (raw)
In-Reply-To: <878rri2i6o.fsf@cjr.nz>
makes sense - do you see anything related in the NTLMSSP doc?
Want to spin up a patch for SMB1 for this?
On 5/3/22 20:35, Paulo Alcantara wrote:
> Byron Stanoszek <gandalf@winds.org> writes:
>
>> I would like to report a regression in the CIFS fs. Sometime between Linux 4.14
>> and 5.16, mounting CIFS with option vers=1.0 (and
>> CONFIG_CIFS_ALLOW_INSECURE_LEGACY=y set appropriately) with security type
>> NTLMSSP stopped working for me. The server side is a Windows 2003 Server.
>>
>> I found that this behavior depends on the length of the Linux client's
>> host+domain name (e.g. utsname()->nodename), where the mount works as long as
>> the name is 16 characters or less. Anything 17 or above returns -EIO, per the
>> following example:
> Looks like your server is expecting the WorkstationName field in
> AUTHENTICATE_MESSAGE payload to be 16 bytes long. That is, NetBIOS name
> length as per rfc1001.
>
>> I implemented a workaround using the following patch:
>>
>> Signed-off-by: Byron Stanoszek <gandalf@winds.org>
>> ---
>> --- a/fs/cifs/cifsglob.h
>> +++ b/fs/cifs/cifsglob.h
>> @@ -101,7 +101,7 @@
>> #define XATTR_DOS_ATTRIB "user.DOSATTRIB"
>> #endif
>>
>> -#define CIFS_MAX_WORKSTATION_LEN (__NEW_UTS_LEN + 1) /* reasonable max for client */
>> +#define CIFS_MAX_WORKSTATION_LEN 16
>>
>> /*
>> * CIFS vfs client Status information (based on what we know.)
>>
>> I don't know if this patch is correct or will have any real effect outside of
>> the NTLMSSP session connect sequence, but it worked in my case.
> Perhaps we should be use TCP_Server_Info::workstation_RFC1001_name in
> fs/cifs/sess.c:build_ntlmssp_auth_blob() instead only when connecting to
> old servers by using insecure dialects -- like SMB1, in your case.
next prev parent reply other threads:[~2022-05-04 5:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 20:36 CIFS regression mounting vers=1.0 NTLMSSP when hostname is too long Byron Stanoszek
2022-05-04 1:35 ` Paulo Alcantara
2022-05-04 5:43 ` Steven French [this message]
2022-05-04 19:15 ` Paulo Alcantara
2022-05-04 20:18 ` Tom Talpey
2022-05-04 20:58 ` Paulo Alcantara
2022-05-06 2:03 ` Steve French
2022-05-06 2:19 ` ronnie sahlberg
2022-05-06 14:05 ` Paulo Alcantara
2022-05-04 7:13 ` Thorsten Leemhuis
2022-05-17 20:37 ` Paulo Alcantara
2022-05-22 4:40 ` Steven French
2022-05-23 2:32 ` Byron Stanoszek
2022-05-25 3:17 ` Byron Stanoszek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7dc6c729-73cd-74be-eec7-ac4a0013f60f@samba.org \
--to=sfrench@samba.org \
--cc=gandalf@winds.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pc@cjr.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.