Force NT1 protocol when listing smb:// network [work in progress]
Needs ReviewPublic

Authored by mikhailnov on Feb 9 2019, 3:02 PM.

Details

Reviewers
sitter
broulik
Group Reviewers
Dolphin
Frameworks
Summary

Samba 4.8 changed default 'client max protocol' from NT1 to SMB3, together with fixes of Badlock, it broke browsing smb:// with default settings, because only NT1 (SMB1) protocol can browse network. Samba 4.10 made it possible to set min/max protocol version via libsmbclient API.
Similar to https://gitlab.gnome.org/GNOME/gvfs/commit/6c8bc39f570ea82cf14e83ce7d1dbdbe569d09d1

BUG: 390551

Diff Detail

Repository
R320 KIO Extras
Lint
Lint Skipped
Unit
Unit Tests Skipped
mikhailnov created this revision.Feb 9 2019, 3:02 PM
Restricted Application added projects: Dolphin, Frameworks. · View Herald TranscriptFeb 9 2019, 3:02 PM
Restricted Application added subscribers: kfm-devel, kde-frameworks-devel. · View Herald Transcript
mikhailnov requested review of this revision.Feb 9 2019, 3:02 PM

Samba developers told that currently other methods of browsong network, than using old SMB1 protocol, are not implemented.

How do dependencies work here? Does this force SMB1 to be installed and enabled in Dolphin now? I ask because many companies have disabled and removed version 1 due to the security issues.

How do dependencies work here? Does this force SMB1 to be installed and enabled in Dolphin now? I ask because many companies have disabled and removed version 1 due to the security issues.

How can smb1 be installed? libsmbclient.so.0 can work using different versions of SMB protocol depending on it's version (but it's API and ABI are stable). It chooses protocol version by itself. SMB2 and SMB3 currently cannot be discovered via NetBIOS by samba, because only smb1 supports netbios discovery, but samba developers have some plans to send DCERPC over smb2/smb3 connections (I don;t know what is DCERPC, but that's what samba developer told me).

Before samba 4.7, NT1 (smb1) the maximum protocol in libsmbclient, if I'm not mistaken; then they made it possible to connect to smb3 servers without manually rising client max protocol, this and/or badlock fixes broke network discovery via smb://, for now, the only way is to manually force NT1 whaen needed, it's what this patch does.

See also https://bugzilla.samba.org/show_bug.cgi?id=13782

ngraham added a subscriber: ngraham.

This fixes https://bugs.kde.org/show_bug.cgi?id=390551, so you can add BUG: 390551 to the Summary section.

As far as I've been able to tell, there are two ways to resolve the problem of un-discoverable shares when using recent versions of Samba:

  1. Fall back to SMB1 for the purpose of share discovery and browsing (which is what 390551 is all about)
  2. Implement the WS-DISCOVERY protocol (tracked with 392447)

Both may ultimately necessary, since old SMB1 servers can only be found with #1, and new shares that have turned off SMB1 compatibility for security purposes (as @acrouthamel talks about) can only be found with #2.

As such, +1 on moving forward with this approach, which is also what the Nautilus and Nemo file managers did to work around the issue.

mikhailnov updated this revision to Diff 51302.Feb 10 2019, 7:54 AM

smbc_setOptionProtocols() does not edit context. smbc_set_context(nullptr) will not change context, but will only return existing one.

P.S. qCDebug(KIO_SMB) does not print anything for some reason now...

mikhailnov edited the summary of this revision. (Show Details)Feb 10 2019, 8:08 AM

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

I cannot approve this. It is opening potential security issues, overrides sysadmin configs, diverges from sound upstream defaults, goes against advise and practises set forth by Microsoft, continues to avoid moving away from a deprecated 30 year old protocol.

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

I cannot approve this. It is opening potential security issues, overrides sysadmin configs, diverges from sound upstream defaults, goes against advise and practises set forth by Microsoft, continues to avoid moving away from a deprecated 30 year old protocol.

Will implementing the WS-DISCOVERY protocol allow discovery of old SMB1 servers too, rendering this unnecessary?

sitter added a comment.EditedFeb 11 2019, 3:13 PM

No. This is already unnecessary. If a user requires SMB1 it may be tuned via /etc/samba/smb.conf.
And that tuning would never be necessary if we had ws-discovery support I think... there is no Windows version which doesn't have ws-discovery and (all?) non-windows systems have DNSSD implementations available. So, between ws-discovery and dnssd pretty much all systems would be supported.

Edit: ...with any possible remainder being up to drop down to SMB1 if the system admin finds that necessary

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

I cannot approve this. It is opening potential security issues, overrides sysadmin configs, diverges from sound upstream defaults, goes against advise and practises set forth by Microsoft, continues to avoid moving away from a deprecated 30 year old protocol.

Those who want highest security desiable smb1 on server side, not client. Also, don't forget about some old versions of Windows or proprietary NAS. Please llet users decide themselves, what is more important for them.
We don't use SMB1 to connect in this patch, we use it _only_ for listing smb://. If you do

smbclient -L localhost

you will see:

Reconnecting with SMB1 for workgroup listing.

But only smbclient command line utility does it, not libsmbclient.so.0, that's why this patch is needed.

No. This is already unnecessary. If a user requires SMB1 it may be tuned via /etc/samba/smb.conf.
And that tuning would never be necessary if we had ws-discovery support I think... there is no Windows version which doesn't have ws-discovery and (all?) non-windows systems have DNSSD implementations available. So, between ws-discovery and dnssd pretty much all systems would be supported.

Edit: ...with any possible remainder being up to drop down to SMB1 if the system admin finds that necessary

I've made this patch mainly to discover Linux machines in the network, and Samba has no implementation of ws-discovery. External not common software like wsdd https://github.com/christgau/wsdd/ has to be installed (and not properly tested network daemons may be a securitry risk without propper isolation like chroot).

Forgot to write that SMB1 is used to list the network, then, when connection is done, protocol version must be chosen again automatically, SMB3 is default in newest samba.

mikhailnov updated this revision to Diff 51443.Feb 11 2019, 9:55 PM

fixed patch

I've done some tests in a clean virtual environment, and must say that this patch actually does not work, because

kioclient5 ls smb:/

does not detect workgroups without setting

[global]
client max protocol = NT1

in ~/.smb/smb.conf

I am very sorry, but I did not notice that it was set on my main machine when I thought that it works...
Does any one have ideas?

mikhailnov retitled this revision from Force NT1 protocol when listing smb:// network to Force NT1 protocol when listing smb:// network [work in progress].

Here is a new prototype of the patch. It builds, but the problem is that SMB connection in kio_smb_auth.cpp is initialized before the URL is parsed in kio_smb_browse.cpp, this makes the logic of this patch not work.