Bug 215375 - Unable to mount cifs 1.0 shares
Summary: Unable to mount cifs 1.0 shares
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: CIFS (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: fs_cifs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-20 12:03 UTC by Davyd McColl
Modified: 2022-05-15 08:36 UTC (History)
5 users (show)

See Also:
Kernel Version: 5.15.5
Tree: Mainline
Regression: No


Attachments

Description Davyd McColl 2021-12-20 12:03:41 UTC
After 5.15.0, I'm unable to mount a CIFS 1.0 share from a media player which I cannot update (vendor no longer provides updates).

Original issue is logged here: https://bugs.gentoo.org/821895, with the most interesting bits probably being:

Steps to Reproduce:
I have an /etc/fstab entry like:
//mede8er/mede8er            /mnt/mede8er-smb  cifs    noauto,guest,users,uid=daf,gid=daf,iocharset=utf8,vers=1.0,nobrl 0 0
1. under 5.14.15, as a regular user, `mount /mnt/mede8er-smb` - mount succeeds
2. reboot to 5.15.{0-5}, as a regular user, `mount /mnt/mede8er-smb` - mount fails

I see the following in /var/log/syslog:
Nov  3 08:00:00 nea kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
Nov  3 08:00:00 nea kernel: CIFS: Attempting to mount \\mede8er\mede8er
Nov  3 08:00:00 nea kernel: CIFS: VFS: \\mede8er failed to connect to IPC (rc=-6)
Nov  3 08:00:00 nea kernel: CIFS: VFS: cifs_mount failed w/return code = -6

I see that there was some cleanup against CIFS and weaker auth algorithms here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c

Now, I'm assuming good reasons for the change, but have to ask:
1. Is it intended that I should not be able to connect to these older devices any more?
2. If so, does anyone know of an alternative method to do so (eg user-space filesystem - I've tried smbnetfs under 5.15.5 to no avail, but perhaps I'm just doing something wrong)

If this is intended behavior, it puts me (and quite likely others) in the position where kernel upgrades on one machine are controlled by the capabilities of another machine, unless there's a reasonable alternative (ie, 2). If it is intended that I should still be able to connect to these shares, I'd appreciate any pointers in the right direction. Kernel configurations are posted at the original issue report, but I can repost here if preferred.

I've reposted here because the original issue seems to have stalled and I'm running hardware (navi amdgpu) which may well benefit, stability-wise, from keeping to the latest kernel, so I'd prefer to do so.
Comment 1 Davyd McColl 2021-12-20 12:06:17 UTC
Apologies, have also tested with 5.15.10 and the issue persists, contra to my original posting of 5.15.{0-5}
Comment 2 The Linux kernel's regression tracker (Thorsten Leemhuis) 2021-12-22 09:01:16 UTC
A question to make me understand this better. The Kconfig text removed by the patch you link to states:

-	  Modern CIFS servers including Samba and most Windows versions
-	  (since 1997) support stronger NTLM (and even NTLMv2 and Kerberos)
-	  security mechanisms.

Is your media player this old? Also: have you tried reverting the change to ensure it's the root of the problem? Alternatively, try to compile the kernel right before the commit and the one with it to check if this really is the issue -- or do a full bisection between 5.14..5.15.
Comment 3 Davyd McColl 2021-12-22 17:39:13 UTC
1. This is a mede8er 600x3d, last updated in APril 2016, and apparently they went with the bare minimum for samba shares.
2. 5.14.15 and below work fine connecting - indeed, what I've been doing is keeping the older kernel around just so that sync tasks from my pc can mount & transfer files to the media player. As soon as 5.15.0 came down on my machine, and up to the current 5.15.10, I've been unable to mount shares from that media player at all. Unfortunately, the last gentoo-sources atom for 5.14 was 5.14.15, though I see at kernel.org that there were releases up to .19

I can do the check you've asked for when I have a moment, if it can be helpful, but I haven't seen any other changes in that area - not that I did an exhaustive search though.
Comment 4 Davyd McColl 2021-12-22 17:54:13 UTC
I'm building commit 18d04062f83b3eedb64e9f64ede26ee83ae7f152 (the parent to the mentioned one) right now and it's making me think that the problem comes in some time later - genkernel is reporting that the version at this commit is 5.14.0-rc7, so if versioning holds up consistently, I would have expected the version here to be > 5.14.15 ): bisecting is going to be a long and arduous process ):
Comment 5 Davyd McColl 2021-12-22 20:01:40 UTC
Ok, 2.5 hours of bisecting later and I can confirm that the culprit is

[76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c] cifs: remove support for NTLM and weaker authentication algorithms

The commit before works fine, this commit prevents me from mounting the smb shares on my mede8er 600x 3d.
Comment 6 Davyd McColl 2021-12-22 20:13:19 UTC
I feel like I need to ask why the auth mechanisms were removed instead of rather put behind config defaulted off? 27 million lines of code in the kernel, removing this code this isn't saving much. I understand the desire to improve security, but the big draw to Linux (at least for me) is the freedom to make my machine do what I want, not what someone else thinks it should do.

OTOH, perhaps there's good reasoning here and I just don't understand it.
Comment 7 Artem S. Tashkinov 2021-12-23 10:29:55 UTC
CC'ing Ronnie Sahlberg who made the commit.
Comment 8 Davyd McColl 2022-01-05 12:30:50 UTC
Mike Pagano has kindly provided a patch to revert this behavior for now (https://bugs.gentoo.org/attachment.cgi?id=761299), so at least I can use the latest kernel with updated drivers. If there's anything I can do to help further with this, please let me know.
Comment 9 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-05 12:52:01 UTC
(In reply to Davyd McColl from comment #8)
> If there's anything I can do to help further with this, please let me know.

I guess it would be a lot better to get this discussed on the list, as bugzilla is bad choice for most subsystems, as explained in https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

But maybe waiting a few more days with that might be worth it, maybe Ronnie shows up and just was AFK due to the festive season.
Comment 10 Ronnie Sahlberg 2022-01-05 20:58:58 UTC
NTLM was removed because it it insecure and we are moving away from insecure options in cifs.
When it comes to NTLM, it was replaced by NTLMv2 decades ago and is not supported in SMB2/3 at all.

In the kernel, some of the crypto dependencies that NTLM depends on are scheduled for removal, thus keeping it will soon require to import and carry replacement crypto and rewrite the APIs that are used, as the crypto will no longer be available via the standard kernel API. With this extra maintenance overhead, as well as that we are moving away from all the insecure options that give CIFS a bad name, we decided to just remove it completely.

The work to remove or disable insecure and obsolete parts of CIFS is ongoing.


This is something that is better to discuss on the mailing list.
Comment 11 Davyd McColl 2022-01-05 21:28:46 UTC
I'd appreciate guidance as to _which_ mailing list I should bring this up in.

The device I'm trying to connect to is a mede8er med600x 3d, last patched in 2018, it runs Linux and this is the only network protocol it supports for transferring files to it.

I totally understand the desire to clean up old code, but in a code-base that is nearly 28 million lines large, on a kernel which still supports some really old and obscure hardware behind configuration flags, it doesn't make sense (to me) that this facility should be completely removed. I would totally understand if it were put behind configuration, defaulted off, but the current situation is that I'm having to reverse the patch at each build and I'm sure that at some point, my reversal patch won't work against changed upstream code, at which time, my choices are to abandon a device which works just fine or run an old VM to support network transfers to this machine, bearing in mind that synchronisation between my main machine and this player happens throughout the day as my main machine downloads media and pushes it to the media player, archiving media that has been watched.

Certainly I can't be the only person affected by this, though I understand that it's probably not a massive audience.
Comment 12 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-07 12:08:43 UTC
(In reply to Davyd McColl from comment #11)
> I'd appreciate guidance as to _which_ mailing list I should bring this up in.

https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html provides some hints. In the end you afaics want to include at least these addresses:

To: lsahlber@redhat.com, Steve French <stfrench@microsoft.com>
CC: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, regressions@leemhuis.info

BTW, maybe this text currently under review is of interest for you (esp. the "Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?" section):

https://lore.kernel.org/linux-doc/7b71a1262b8b72d30154203bb14f00db7d4170ef.1641203216.git.linux@leemhuis.info/

But fwiw, this afaics is one of those tricky issues where not fixing *might* be the right things to do. But maybe some solution can be found to make everyone happy.
Comment 13 Robert Schultz 2022-01-07 17:52:49 UTC
(In reply to Davyd McColl from comment #11)
> Certainly I can't be the only person affected by this, though I understand
> that it's probably not a massive audience.

No, you are not. I'm also affected. I run several Win2k machines under QEMU that I map to from my host Linux OS, which stopped working once I updated to Kernel 5.15.12. That's why I made the patch on the Gentoo thread to backport this feature back into the kernel.

I'm not aware of any other method under linux to mount CIFS NTLM shares (for example, no FUSE driver that I'm aware of). So if the decision stands to keep this removed from the kernel, I'll just keep patching it back into every future kernel release.

Sorry for posting this response here, it seems the preferred method is the regressions mailing list, but I wasn't able to subscribe to it, mailing list server replied with a "Blocked by SpamAssassin" response.
Comment 14 Davyd McColl 2022-01-10 06:05:11 UTC
I've attempted to send an email to the above addresses, but two (as far as I can tell) have bounced it because it was unfortunately encoded as html, even though there was no formatting involved. I'll try to send again, though the two email clients I use (Mailspring and Mailbird) don't seem to surface a way to send a mail as plaintext.
Comment 15 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-10 12:16:14 UTC
(In reply to Davyd McColl from comment #14)
> I've attempted to send an email to the above addresses, but two (as far as I
> can tell) have bounced it because it was unfortunately encoded as html

I just replied as plain text with a full quote, that way everyone should see it.
Comment 16 Jim Avera 2022-05-15 02:15:46 UTC
It's not just old media servers.   Many routers serve network-attached USB disks  but older models (like mine) only offer cifs 1.0.

I too do not understand the decision to cut off support for legacy cifs servers.  Is there a strong technical motivation for this?  Is the existence of the old code seriously impeding forward progress?   Are those "crypto depdendencies" to be removed simply no-longer-secure, or are they actively causing trouble somehow?

Suggest renaming old algos/apis "insecure_xxx" to make their status crystal clear, and maybe #ifdef the code so embedded kernels can save memory be omitting them

Please don't jettison support for legacy hardware without at least mildly compelling reasons, and then only after lots of advance notice so people can replace their to-be-orphaned hardware in advance.
Comment 17 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-05-15 08:36:31 UTC
Here only a few people will notice your comment; your opinion is way more likely to get heard my joining the mailing discussion about this, where Linus himself weighted in:

https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/

Feel free to reply there.

Note You need to log in before you can comment on or make changes to this bug.