Bug 13051 - "smb encrypt" setting changes are not fully applied until full smbd restart
"smb encrypt" setting changes are not fully applied until full smbd restart
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.7.0
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-25 22:43 UTC by Justin Maggard
Modified: 2017-12-06 09:19 UTC (History)
3 users (show)

See Also:


Attachments
Possible patch for master (3.59 KB, patch)
2017-11-21 14:34 UTC, Ralph Böhme
no flags Details
Patch for 4.6 and 4.7 cherry-picked from master (5.48 KB, patch)
2017-11-30 09:13 UTC, Ralph Böhme
jra: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Maggard 2017-09-25 22:43:44 UTC
If we change the "smb encrypt" setting from "default" to "required", clients are still able to list share names and connect to services without encryption (although actual file transactions seem to be blocked).  This state remains until smbd is completely restarted -- not even a service reload using SIGHUP works.

Conversely, if we change the "smb encrypt" from "required" to "default", clients continue to be denied unencrypted access to the Samba server until after a full smbd restart.

For example:

jmaggard@justin-rn626:~$ testparm -s 2>/dev/null | grep "smb encrypt"
jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents
Enter DISCOVERY\jmaggard's password: 
Disk|Documents|
Disk|dr1|
Disk|import|
Disk|Music|
IPC|IPC$|IPC Service ("justin-rn626")
Disk|jmaggard|Home directory of jmaggard
Reconnecting with SMB1 for workgroup listing.
Workgroup|DISCOVERY|JUSTIN-RR4360

jmaggard@justin-rn626:~$ testparm -s 2>/dev/null | grep "smb encrypt"
	smb encrypt = required
jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents
Enter DISCOVERY\jmaggard's password: 
Disk|Documents|
Disk|dr1|
Disk|import|
Disk|Music|
IPC|IPC$|IPC Service ("justin-rn626")
Disk|jmaggard|Home directory of jmaggard
Reconnecting with SMB1 for workgroup listing.
Workgroup|DISCOVERY|JUSTIN-RR4360

jmaggard@justin-rn626:~$ sudo systemctl restart smb
jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents
Enter DISCOVERY\jmaggard's password: 
Error returning browse list: NT_STATUS_ACCESS_DENIED
Reconnecting with SMB1 for workgroup listing.
Comment 1 Jeremy Allison 2017-09-25 23:13:08 UTC
Hmmmm. You can only reproduce this with SMB1 - correct ?

I'm guessing it doesn't happen with SMB2+.

This might be an artifact of the way encryption is implemented in SMB1, which requires a tran2 call *after* the share connection, so this may be a "just implemented that way" kind of thing (i.e. it probably always did this for the SMB1 unix extensions encryption).

If this causing a problem at customer sites, or just something you noticed ?

Jeremy.
Comment 2 Justin Maggard 2017-09-26 00:11:46 UTC
The "conversely" portion (required -> desire, enabled, or disabled) caused the complaint in the field, and that is reproducible on both SMB1 and SMB2.

But you're correct, the first issue with upgrading the encryption requirement is not reproducible using SMB2.
Comment 3 Ralph Böhme 2017-11-21 14:21:15 UTC
Working on a fix...
Comment 4 Ralph Böhme 2017-11-21 14:34:57 UTC
Created attachment 13798 [details]
Possible patch for master

Jeremy, if you're curious, here's what I have... :) Not requesting formal review yet though.
Comment 5 Ralph Böhme 2017-11-30 09:13:07 UTC
Created attachment 13828 [details]
Patch for 4.6 and 4.7 cherry-picked from master
Comment 6 Jeremy Allison 2017-11-30 21:02:41 UTC
Re-assigning to Karolin for inclusion in 4.7.next, 4.6.next.
Comment 7 Karolin Seeger 2017-12-05 09:26:42 UTC
(In reply to Jeremy Allison from comment #6)
Pushed to autobuild-v4-{7,6}-test.
Comment 8 Karolin Seeger 2017-12-06 09:19:46 UTC
Pushed to both branches.
Closing out bug report.

Thanks!