3.3.5.5 Receiving an SMB_COM_NT_CREATE_ANDX Request

  • Article

The processing of an SMB_COM_NT_CREATE_ANDX request is handled as specified in [MS-CIFS] section 3.3.5.51 with the following additions:

When opening a named pipe, if the ImpersonationLevel level is SECURITY_DELEGATION, the server MUST fail the request with STATUS_BAD_IMPERSONATION_LEVEL.

If during the open processing the underlying object store returns STATUS_ACCESS_DENIED as specified in [MS-FSA] section 2.1.5.1, Server Requests an Open of a File, the server MUST fail the request with STATUS_ACCESS_DENIED and MUST increase ServerStatistics.sts0_permerrors by 1.

If the underlying object store determines that encryption processing is required as specified in [MS-FSA] section 2.1.5.1 Server Requests an Open of a File, the object store MUST return STATUS_CS_ENCRYPTION_EXISTING_ENCRYPTED_FILE if the encrypted file exists or STATUS_CS_ENCRYPTION_NEW_ENCRYPTED_FILE if the file to be created will be encrypted, indicating that a UserCertificate is necessary to successfully complete the operation. In these cases, the server SHOULD attempt to obtain a user certificate by invoking the Application Requests for a User-Certificate Binding as specified in [MS-EFSR] section 3.1.4.1, passing the Server.Session.SecurityContext as the security context of the user. If the enrollment fails, the server MUST fail the request with the resulting error. Otherwise, the server SHOULD repeat the handling as specified in [MS-CIFS] section 3.3.5.51, extended<116> to additionally pass the returned certificate to the object store as the UserCertificate argument.

If FILE_DELETE_ON_CLOSE is set in the CreateOptions field and any of the following conditions is TRUE, the server SHOULD<117> fail the request with STATUS_ACCESS_DENIED.

  • DesiredAccess does not include DELETE or GENERIC_ALL.

  • Server.Treeconnect.MaximalAccess does not include DELETE or GENERIC_ALL.

The server MUST ignore all CreateOptions on a named pipe except FILE_WRITE_THROUGH, FILE_SYNCHRONOUS_IO_ALERT, and FILE_SYNCHRONOUS_IO_NONALERT.

For a named pipe request, if the client sets FILE_SYNCHRONOUS_IO_ALERT or FILE_SYNCHRONOUS_IO_NONALERT bits in the CreateOptions field and does not set the SYNCHRONIZE bit in the DesiredAccess field, the server MUST fail the Open request with STATUS_INVALID_PARAMETER.

On a successful create or open, if the NT_CREATE_REQUEST_EXTENDED_RESPONSE flag was set in the Flags field of the request, the server SHOULD<118> send an extended response (section 2.2.4.9.2).

If the server sends the new response, it MUST construct a response as specified in section 2.2.4.9.2, with the addition of the following rules:

  • The server MUST query the underlying object store for file attributes and SHOULD<119> set the FileStatusFlags in the response, in an implementation-specific manner.

  • If the underlying object store of the share in which the file is opened or created does not support streams, then the server MUST set the NO_SUBSTREAMS bit in the FileStatusFlags field.<120>

  • The server SHOULD<121> set the VolumeGUID and FileId fields to zero.

  • The server MUST query the underlying object store for the granted access rights on the returned Server.Open. The server MUST use the granted access rights and SHOULD<122> set the MaximalAccessRights and GuestMaximalAccessRights fields in an implementation-specific manner. If the file has no security applied, MaximalAccessRights MUST be set to 0xFFFFFFFF. The server MUST use Open.Session.UserSecurityContext to impersonate the client.

If Server.IsDfsCapable is TRUE and Server.Share.IsDfs is True, then server MUST invoke the interface defined in [MS-DFSC] section 3.2.4.1 to normalize the pathname by supplying FileName as the input parameter. If normalization fails, the server MUST fail the create request with the error code returned by the DFS normalization routine.  If the normalization procedure succeeds, returning an altered target name, the FileName field MUST be set to the normalized path name, and used for further operations specified in section in [MS-CIFS] section 3.3.5.51.

If any intermediate component of the path specified in the create request is a symbolic link, the server MUST return an error as specified in section 2.2.7.1.2. Symbolic links MUST NOT be evaluated by the server.

If the final component of the path is a symbolic link, the server behavior depends on whether the flag FILE_OPEN_REPARSE_POINT is specified in the CreateOptions field of the request. If FILE_OPEN_REPARSE_POINT is specified, the server MUST open the underlying file or directory and return a handle to it. Otherwise, the server MUST return an error as specified in section 2.2.7.1.2.