[Samba] SMB Multichannel not working?

[Carter Sheehan]

Jeremy,

Are you suggesting we need more debugging on the client or server side or both?


Carter Sheehan
Cloud Engineer
d: +1 (781) 224-7753
e: csheehan at vestmark.com

This e-mail and any attachments hereto, are intended for use by the addressee(s) only and may contain information that is confidential information of Vestmark, Inc. If you are not the intended recipient of this e-mail, or if you have otherwise received
this e-mail in error, please immediately notify me by telephone or by e-mail, and please permanently delete the original, any print outs and any copies of the foregoing. Any dissemination, distribution or copying of this e-mail is strictly prohibited.
________________________________
From: Jeremy Allison <jra at samba.org>
Sent: Monday, February 6, 2023 9:13 PM
To: Carter Sheehan <csheehan at vestmark.com>
Cc: samba at lists.samba.org <samba at lists.samba.org>
Subject: Re: [Samba] SMB Multichannel not working?


External Email
This email was NOT sent from someone at Vestmark


On Tue, Feb 07, 2023 at 12:23:29AM +0000, Carter Sheehan wrote:
> Jeremy,
> Once again, thank you for the time; I owe you a coffee my friend!
> "So your original report that Samba doesn't set the MULTI CHANNEL
> bit was incorrect, we do (and in the right place)."
> I would like to clarify that I was really just confused by the first SMBv2
> response I got from the server (packet 6 in the capture), because the
> capabilities had multichannel disabled
>     .... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does
> NOT support ENCRYPTION
> but the client request/response packets after that do have MC enabled as
> you pointed out. I was just simply confused by the switch between the two
> responses from the server, but that is probably a red-herring.

No worries !

> As for the differences in the IPC connection, that is a very interesting
> find! Our config file is very barebones and we have explicitly set "read
> only = no" on a few of our shares. The "filestore" share is not a read
> only share. Do you have any suggestions for a config that would be
> "unrestrictive" to enable us to test your theory?

The bits missing in the tcon reply are those explicitly removed
by create_share_access_mask().

static uint32_t create_share_access_mask(int snum,
bool readonly_share,
const struct security_token *token)
{
uint32_t share_access = 0;

share_access_check(token,
lp_const_servicename(snum),
MAXIMUM_ALLOWED_ACCESS,
&share_access);

if (readonly_share) {
share_access &=
~(SEC_FILE_WRITE_DATA | SEC_FILE_APPEND_DATA |
SEC_FILE_WRITE_EA | SEC_FILE_WRITE_ATTRIBUTE |
SEC_DIR_DELETE_CHILD );
}
...

The missing bits in your tcon reply are exactly:

~(SEC_FILE_WRITE_DATA | SEC_FILE_APPEND_DATA |
SEC_FILE_WRITE_EA | SEC_FILE_WRITE_ATTRIBUTE |
SEC_DIR_DELETE_CHILD );

so I'm guessing that this user doesn't have write
access to this data. The share access mask is created
inside source3/smbd/smb2_service.c:make_connection_snum()
when it calls check_user_share_access().

589 /*
590 * Set up the share security descriptor.
591 * NOTE - we use the *INCOMING USER* session_info
592 * here, as does (indirectly) change_to_user(),
593 * which can be called on any incoming packet.
594 * This way we set up the share access based
595 * on the authenticated user, not the forced
596 * user. See bug:
597 *
598 * https://bugzilla.samba.org/show_bug.cgi?id=9878<https://bugzilla.samba.org/show_bug.cgi?id=9878>
599 */
600
601 status = check_user_share_access(conn,
602 session->global->auth_session_info,
603 &conn->share_access,
604 &conn->read_only);

conn->share_access is what is returned in the tcon access
field.

You might need to add lots more debugging to see what is
going on here.