Red Hat Bugzilla – Bug 1459559
security = share stops working when samba-3.6.23-43.el6_9.x86_64 installed
Last modified: 2017-08-16 12:41:06 EDT
Description of problem:
When upgragrading samba because of CVE-2017-7494 shares become not avaliable due to newer version doesn't work with the security = share option.
RHEL 6.8/6.9 with samba-3.6.23-43.el6_9.x86_64 and security = share
Version-Release number of selected component (if applicable):
trivial config RHEL 6.8/6.9 with samba-3.6.23-43.el6_9.x86_64 and security = share, shares not avaliable
shares not avaliable
workgroup = TEST
netbios name = TEST
security = share
log level = 10 all:10
; max protocol = SMB2
comment = Testshare
path = /export
read only = Yes
guest only = Yes
I'm sorry but the patch for CVE-2017-7494 has nothting to do with 'security = share' mode.
The badlock patches fix several security issues. 'security = share' is opening a security issue so with the badlock patches it is not working anymore!
Note that 'security = share' has been deprecated in Samba 3.6 and has been removed in Samba 4.0 completely.
Migrate to 'security = user'
If he claims that it only happens with this release version (release 43), then get logs with 'log level = 1' set while reproducing the issue.
The fix for CVE-2017-7494 creates a log entry with debug level 1. So I did the following:
grep "Refusing open on pipe" log.smbd from the sos report.
There is no such log entry. So the code from the patch for CVE-2017-7494 is not executed!
This is not a regression from the fix for CVE-2017-7494 as I already state in comment #2.
Last year we fixed several security issues  around the badlock bug . These were:
As Samba is not maintained by upstream anymore Red Hat backported the required patches to address the security issues discovered. We backported a total of 127 patches, adding ~3000 loc.
The 'security = share' mode itself opens an attack surface for MITM attacks. The patches to fix the mentioned security issues from above prevent those MITM attacks.
This means with those fixes we are no longer able to support 'security = share'. Supporting it would mean we open security holes in the software.
Not that 'security = share' has been deprecated in Samba 3.6 and has been removed with the release of Samba 4.0. Customers are advised since Samba 3.6 to migrate to 'security = user'.
The questions is why is the customer not able to migrate to 'security = user'.
Especially for the config posted in the initial comment, we do not see an issue using 'security = user'.
security = user
map to guest = bad user
is all which is needed.
NOTE: There is no upstream release for Samba 3.6 including the security patches for:
and a lot more.