[Samba] SMB Multichannel not working?

[Jeremy Allison]

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
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.