[cifs-protocol] [MS-SMB2] 3.3.5.9.12 - CreateGuid lookup use case - TrackingID#2503250040016233

[Kristian Smith]

Hi Slow,

I have created a new case for the CreateGuid lookup use case question (and adjusted the subject line). I'll do some research and get in touch with you soon.

Regards,
Kristian Smith
Support Escalation Engineer | Microsoft® Corporation
Email: kristian.smith at microsoft.com

-----Original Message-----
From: Ralph Boehme <slow at samba.org> 
Sent: Tuesday, March 25, 2025 11:43 AM
To: Kristian Smith <Kristian.Smith at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: [EXTERNAL] Re: MS-SMB2 3.3.5.9.12 Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 Create Context - TrackingID#2503170040010814

Hi Kristian,

On 3/25/25 12:42 AM, Kristian Smith wrote:
> I've been looking into this issue relating to MS-SMB2 3.3.5.9.12. I'll provide an interpretation and if it doesn't make sense, just let me know.
> 
>  From MS-SMB2 3.3.5.9.12:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------
> The processing changes involved for this create context are:
> §       The server MUST look up an existing Open in the GlobalOpenTable by doing a lookup with the FileId.Persistent portion of the create context.
> §       If the lookup fails:
> §               If the request includes the SMB2_DHANDLE_FLAG_PERSISTENT bit in the Flags field of the SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 create context, TreeConnect.Share.IsCA is TRUE, and Connection.ServerCapabilities includes SMB2_GLOBAL_CAP_PERSISTENT_HANDLES, the server MUST look up an existing Open in the GlobalOpenTable by doing a lookup with the CreateGuid of the create context. If the lookup fails, the server SHOULD<336> fail the request with STATUS_OBJECT_NAME_NOT_FOUND and proceed as specified in "Failed Open Handling" in section 3.3.5.9.
> §               Otherwise, the server SHOULD<337> fail the request with STATUS_OBJECT_NAME_NOT_FOUND and proceed as specified in "Failed Open Handling" in section 3.3.5.9.
> ----------------------------------------------------------------------
> -----------------------------------------------------------------
> 
> Alternate interpretation of MS-SMB2 3.3.5.9.12 as seen above:
> ----------------------------------------------------------------------
> -----------------------------------------------------------------
> How this context differs from a standard CREATE:
>          Server MUST lookup the open with FileID.Persistent
>          If this lookup fails using FileID.Persistent:
>                  If this is a CA share with persistent handle flagged in the request, and the server is capable of persistent handles:
>                          Try the lookup again, but with the CreateGuid
>                          If the lookup with CreateGuid fails:
>                                  The server SHOULD<345> fail w/ STATUS_OBJECT_NAME_NOT_FOUND and proceed w/ "Failed Open Handling" procedure
>                  If this is either not a CA Share, not a persistent handle request, or the server is not capable of persistent handles:
>                          The server SHOULD<346> fail w/ 
> STATUS_OBJECT_NAME_NOT_FOUND and proceed w/ "Failed Open Handling" 
> procedure
> ----------------------------------------------------------------------
> -----------------------------------------------------------------
> 
> Since the context explanation calls out that these are the "processing changes involved for this create context", the document makes the assertion that all other conditions should follow that of a normal CREATE. This would include the behavior when the lookup succeeds.
> 
> Please let me know if you have any additional questions.

adding indentation as you did above solves the problem I had which was what condition was the "otherwise" related to, thanks.

A follow up question comes up though: what is the usecase / protocol scenario this create-guid lookup is trying to solve?

My understanding was that the create-guid is what ties things togehter for create *replay* where the client hasn't yet the create response from the server and hence doesn't know the FileID.Persistent.

In the context of DHv2 *reconnect* how can the lookup for FileID.Persistent legally fail in the first place? The server MUST have successfully processes the initial create request and MUST have somhow persisted the handle state, so which is the scenario that this fallback lookup is trying to solve?

*scratches head*

Thanks a lot!
-slow