[Samba] SMB Multichannel not working?

Jeremy Allison jra at samba.org
Tue Feb 7 02:13:08 UTC 2023

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;


         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
599          */
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

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

More information about the samba mailing list