[cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Bill Wesse
billwe at microsoft.com
Wed Nov 25 10:14:26 MST 2009
Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing.
I will continue my investigation into the details on the differences between the base & pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents.
Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS-CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx).
SMB_INFO_PASSTHROUGH levels request a native Windows NT operating system information level (as you already have noted) of the TRANS2_SET_* & TRANS2_QUERY_* calls, and can be thought of as rough equivalents to ZwSetInformationFile and ZwQueryInformationFile:
1. Where the 'FILE_INFORMATION_CLASS FileInformationClass' parameter is equal to:
(InformationLevel - SMB_INFO_PASSTHROUGH) : See MSDN WDF_FILE_INFORMATION_CLASS at
http://msdn.microsoft.com/en-us/library/dd568296.aspx
2. The InformationLevels are restricted as noted in:
[MS-SMB] 6 Appendix A: Product Behavior <158>, <239>, <240> and <242> at
http://msdn.microsoft.com/en-us/library/cc246806.aspx
[MS-FSCC] 5 Appendix A: Product Behavior note <47> specifies "Windows uses the NtQueryInformationFile ... NtSetInformationFile ... The definition of the function used to process any file information request, including its content and the function signature, is implementation-dependent and is not part of the protocol specification".
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
-----Original Message-----
From: Bill Wesse
Sent: Wednesday, November 25, 2009 8:30 AM
To: 'Tim Prouty'
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Good morning Tim. Bill Wesse from the Documentation Support team here. I will be your contact for this issue. We have created the following case to track our investigation:
SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode
I will begin work this morning, and will update you with status before the end of the day.
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
-----Original Message-----
From: Tim Prouty [mailto:tim.prouty at isilon.com]
Sent: Tuesday, November 24, 2009 6:07 PM
To: Interoperability Documentation Help; cifs-protocol at samba.org; pfif at tridgell.net
Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hi,
Based on the ZwSetInformationFile() docs
(http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file.
The specific case I'm interested in is the following:
1. Client1 does a CreateFileAndX() on a non-existant file with a share
mode of 0 and holds the file open.
2. Client 2 does a Trans2SetPathInfo() with the level set to
FileEndOfFileInformation (0x104) as documented in the SNIA CIFS
spec. As expected NT_STATUS_SHARING_VIOLATION is returned here.
3. Client 2 does a Trans2SetPathInfo() with the undocumented
pass-through level that also allows setting the
FileEndOfFileInformation (1020 / 0x3FC). The client specifies that
it wants to extend the file size to 100. Interestingly, win7 and
winXP will return NT_STATUS_SUCCESS and successfully extend the
length of the file. This operation seems to be circumventing the
share mode enforcement.
Is #3 actually correct behavior that other servers should implement?
If so, can the cases where share modes are not enforced be enumerated in the documentation?
I have attached a pcap of a client executing these exact steps against a win7 server.
Packet 27/28: Step 1
Packet 29/30: Step 2
Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced.
Thanks!
-Tim
More information about the cifs-protocol
mailing list