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

Tue Dec 8 07:07:55 MST 2009

Good morning Tim - here is a summary of my progress to-date concerning your questions.

==============================================================================
Question:

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?

Response:

#3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation is
functionally equivalent to a remote call to NtSetInformationFile.

NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the file
system driver in question; this does not involve the usual I/O Manager
ShareMode checks.

==============================================================================
Question:

If a client can send a particular info level and windows implements
it, then we have a compatibility problem if we choose not to support
it.  What I would really like to know is if other SMB implementations
need to circumvent share-mode checks for this pass through level (and
maybe others?).

Response:

This should be the case for all supported SMB_INFO_PASSTHROUGH levels, as they
run through the same essential logic.

However, I have additional testing to perform before I can completely confirm
this.

==============================================================================
Question:

I have done some more investigation on this issue, particularly around
doing a Trans2SetPathInfo() with the documented
FileEndOfFileInformation (0x104) level.  It returns what I would
expect to be an acceptable error for an unknown info level.  I have
attached a trace that shows this being done against a win7 server, but
I have a question about what the server is returning.  The packets of
interest are 39/40:

1. Packet 40 appears to have the WordCount and ByteCount truncated,
    making the packet smaller than normal minimum size of 35?  Is this
    intended behavior that other servers should implement?

Additionally a DOS Error is returned instead of a standard NT_STATUS
error.  MS-CIFS does say that a DOS error or an NT_STATUS error may be
returned, but I don't see any indication in the documentation of when
a DOS error should be returned instead of an NT_STATUS error.  Is it
possible to make this explicit in the docs or is this a case where
it's purposefully left ambiguous?

Response:

The WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem
(trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my
clients (who succeeded against the call).

I have attached a zip file with your trace (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace (test_trans2setpathinfo_Win7.pcap). Mine does not have that second Set EOF call. Do I need a newer build of smbtorture (my current one from you is samba.2009.12.01.tar.gz)?

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: Friday, December 04, 2009 12:45 PM
To: 'Tim Prouty'
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

Thanks for the update - my Win7 client is also Ultimate, with no updates.

On another note, I just finished an initial debug on srv.sys; I have considerable analysis to do on the results, specifically tracking down the handles (just to make sure - even though there are no handle failures in either standard or SMB_INFO_PASSTHROUGH FileEndOfFileInformation information level for TRANS2_SET_PATH_INFORMATION).

There are additional functional checks on the information level, when less than SMB_INFO_PASSTHROUGH, which I still need to run down in the documentation.

I doubt I will be able to finish my work today, and do expect to be able to provide some reasonable information early next week.

Of course, this is all about what is supposed to be allowed when a client requests a 'native Windows NT operating system information level' ([MS-SMB] Appendix A note <158>: http://msdn.microsoft.com/en-us/library/cc246806(PROT.13).aspx).

I have thus far not been able to find any specific commentary on this in the WDK documentation (but then, I am not a driver expert).

Thanks for your patience!

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: Friday, December 04, 2009 12:20 PM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote:

> I have retested without SmbSecuritySignatures - results were the same.
>
> I will hold off on the WordCount/ByteCount truncation against the  
> Dos INVALID_LEVEL error problem  
> (trans2setpathinfo_against_win7_2.pcap) for the time being, and work  
> on the sharing issue (I expect to be soaking in code for the next  
> day or so).

My win7 is a fresh ultimate install with no updates.  I'm going to run  
windows update to see if I can reproduce it.  I'll let you know what I  
find out.

-Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Win7Traces.zip.bin
Type: application/octet-stream
Size: 10667 bytes
Desc: Win7Traces.zip.bin
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091208/8842819a/attachment-0001.bin>