[cifs-protocol] [REG:113011010129494] FSCTL_SRV_COPYCHUNK overlapping ranges

[Edgar Olougouna]

David,
Please find answers as follows:

Comment 2) 
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.

Answer to comment 2)

Windows Server 2008r2's copy chunk behavior will be clarified as part of the update to SR 112120410054506 (FSCTL_SRV_COPYCHUNK locking discrepancies between Windows versions)
Recall that CopyChunk in Windows Server 2012 use regular Readfile/Writefile APIs to move the chunks from the source to the destination; whereas prior to Windows Server 2012, CopyChunk used mapped sections to move the data. 

Comment 1)
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).

Answer to comment 1)

We reviewed the processing of FSCTL_SRV_COPYCHUNK regarding FILE_READ_DATA access on the destination handle. 
The <<server>> does not validate FILE_READ_DATA access on the destination handle.
The original FSCTL code (FSCTL_SRV_COPYCHUNK) was defined such that the IOCTL itself implies that “read access is required”; this validation is enforced by the IO manager on the <<Windows client>> to validate that read access is granted on the destination handle before issuing the FSCTL. This prevented copy chunk when the target was opened with only write access.
The second FSCTL code (FSCTL_SRV_COPYCHUNK_WRITE) solved that issue and is defined as “write access is required” even if on the <<Windows client>> side they might go through the same code path.

Here are some relevant excerpts from MS-SMB2:

2.2.31   SMB2 IOCTL Request
FSCTL_SRV_COPYCHUNK and FSCTL_SRV_COPYCHUNK_WRITE FSCTL codes are used for performing server side copy operations. These FSCTLs are issued by the application against an open handle to the target file. FSCTL_SRV_COPYCHUNK is issued when a handle has FILE_READ_DATA and FILE_WRITE_DATA access to the file; FSCTL_SRV_COPYCHUNK_WRITE is issued when a handle only has FILE_WRITE_DATA access.

3.2.4.20.2.2   Application Requests a Server Side Data Copy
The application provides: 
	A handle to the Open identifying the destination file.
	The FSCTL code for the server side copy, either FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE.<121>
…

<121> Section 3.2.4.20.2.2: Windows applications use FSCTL_SRV_COPYCHUNK if the target file handle has FILE_READ_DATA access. Otherwise, they use the FSCTL_SRV_COPYCHUNK_WRITE.

Regards,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Thursday, January 10, 2013 12:39 PM
To: 'David Disseldorp'
Cc: cifs-protocol at cifs.org; pfif at tridgell.net; MSSolve Case Email
Subject: RE: [REG:113011010129494] FSCTL_SRV_COPYCHUNK overlapping ranges

[Updating subject with new case number 113011010129494]

David,

Thanks for the feedback.

This case will be addressing the remaining comments regarding the update to [MS-SMB2] 3.3.5.15.6   Handling a Server-Side Data Copy Request:

The remaining two comments:

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

Regards,
Edgar

-----Original Message-----
From: David Disseldorp [mailto:ddiss at suse.de]
Sent: Thursday, January 10, 2013 8:34 AM
To: David Disseldorp
Cc: Edgar Olougouna; cifs-protocol at cifs.org; pfif at tridgell.net; MSSolve Case Email
Subject: Re: [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges

On Wed, 2 Jan 2013 17:08:47 +0100
David Disseldorp <ddiss at suse.de> wrote:

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

Sorry, disregard this incorrect comment. I was testing with execute access inherently granting read access.

Regards, David