[cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

Tim Prouty tim.prouty at isilon.com
Tue Nov 24 16:07:03 MST 2009


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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: trans2setpathinfo_against_win7.pcap
Type: application/octet-stream
Size: 8701 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091124/4e3b2d5f/attachment.obj>

More information about the cifs-protocol mailing list