[cifs-protocol] MS-SMB2 3.3.5.9.12 Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 Create Context - TrackingID#2503170040010814

[Ralph Boehme]

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