[cifs-protocol] [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges
ddiss at suse.de
Wed Jan 2 09:08:47 MST 2013
On Thu, 20 Dec 2012 22:20:12 +0000
Edgar Olougouna <edgaro at microsoft.com> wrote:
> We have completed our investigation on this issue regarding server handling of SMB2 FSCTL_SRV_COPYCHUNK overlapping ranges. As a result a future release of MS-SMB2 will include the following updates.
> The attached pdf to this email contains the changes with highlights of the updates.
Thanks a lot for your investigation and subsequent documentation update.
Please see some further comments below...
> Provisional MS-SMB2 changes
> 18.104.22.168 Per Open
> Open.ResumeKey: A 24-byte key that identifies a source file in Server side Data Copy Operation.
> 22.214.171.124.5 Handling a Source File Key Request
> The server MUST provide a 24-byte value that is used to uniquely identify the open. The server SHOULD use Open.DurableFileId, or alternately, MAY use an internally generated value that is unique for all opens on the server.<283>The server MUST set Open.ResumeKey and ResumeKey in SRV_REQUEST_RESUME_KEY Response to the generated value.
> 126.96.36.199.6 Handling a Server-Side Data Copy Request
> When the server receives a request with an SMB2 header with a Command value equal to SMB2 IOCTL, and a CtlCode of FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE, message handling proceeds as follows:
> The server MUST locate the source open from where data will be read by locating the open where Open.ResumeKey matches SourceKey received in the SRV_COPYCHUNK_COPY structure received in the buffer described by InputCount and InputOffset of the SMB2 IOCTL Request. If the open is not found, the server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND.
> If OutputCount in SMB2 IOCTL request is less than the size of SRV_COPYCHUNK_RESPONSE structure, the server MUST fail the SMB2 IOCTL request with STATUS_INVALID_PARAMETER.
> If OutputCount in SMB2 IOCTL request is greater or equal to the size of SRV_COPYCHUNK_RESPONSE structure and under any of the following conditions, the server MUST send an SMB2 IOCTL Response as specified in section 188.8.131.52.6.2:
> * InputCount in SMB2 IOCTL request is less than the size of Buffer field containing SRV_COPYCHUNK_COPY structure
> * ChunkCount is greater than ServerSideCopyMaxNumberofChunks
> * Length in a single chunk is greater than ServerSideCopyMaxChunkSize or equal to zero
> * Sum of Lengths in all chunks is greater than ServerSideCopyMaxDataSize
> * TargetOffset in any chunk is less than zero but not equal to 0xFFFFFFFFFFFFFFFF.
> * Open.TreeConnect of the source or destination file is on a named pipe filesystem
These changes appear to be more targeted at copychunk error response
handling (REG:112110862761681), but are useful nevertheless.
> If Open.GrantedAccess of the destination file does not include FILE_WRITE_DATA or FILE_APPEND_DATA, then the request MUST be failed with STATUS_ACCESS_DENIED. If Open.GrantedAccess of the source file does not include FILE_READ_DATA access, then the request MUST be failed with STATUS_ACCESS_DENIED.
I think the entry stating the destination file FILE_READ_DATA access
requirement for FSCTL_SRV_COPYCHUNK should remain here, as Windows
servers appear to implement this (tested against 2012 and 2008r2).
Furthermore, FILE_READ_DATA access on the source file does not appear to
be required. I'd planned to raise this as a separate DocHelp issue.
> If Open.TreeConnect.Session of the destination file is not equal to Open.TreeConnect.Session of the source file, the server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND.
> Starting with the first chunk received in the Chunks field and for each chunk, the server MUST apply the following processing rules:
> * The server MUST issue a read using the SourceOffset and Length from the source file.<284> If the SourceOffset or SourceOffset + Length extends beyond the end of file, the server SHOULD<285> treat this as a STATUS_END_OF_FILE error. If the read fails, the server MUST map the error code returned to a valid status code as described in section 2.2, and MUST send an SMB2 IOCTL response as specified in Sending a Copy Failure Server-Side Copy Response (section 184.108.40.206.6.1).
> * If the read operation is successful, the server MUST issue a write of the data read using the TargetOffset and Length in the range against the destination file.<286> If the write fails, the server MUST send an SMB2 IOCTL response as specified in Sending a Copy Failure Server-Side Copy Response (section 220.127.116.11.6.1).
This may imply that the entire chunk must be read and then subsequently
written, contrary to Windows Server 2008r2's sub chunk-length (2048
byte) copy behaviour described in the initial report. Perhaps an extra
Product Behaviour caveat should be added to clarify this.
More information about the cifs-protocol