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

Fri Dec 18 12:06:49 MST 2009

Bill, Thank you for diving into this issue and bringing clarity to how  
others should be implementing this.  I sincerely appreciate your  
dilligence!

-Tim

On Dec 18, 2009, at 5:38 AM, Bill Wesse wrote:

> Good morning Tim - development has responded to the TDI - thank you  
> very much for finding and reporting this - as well as for the  
> opportunity for us to improve our implementation and documentation!  
> Please let me know if this answers your question satisfactorily; if  
> so, I will consider your question resolved.
>
> ==========
>
> The behavior exhibited on SMB1 regarding not receiving a sharing  
> violation when doing a set of FileEndOfFileInformation when write  
> sharing is disallowed is a bug in our server implementation.
>
> This is something we will pursue fixing, and the behavior does not  
> exist for the FID-based set info in SMB1 or the set-info command in  
> SMB2.  We are investigating the best path to fix the issue and then  
> update the documentation accordingly.  It seems to exist inside the  
> Path-based SetInfo path.
>
> ==========
>
> 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, December 16, 2009 2:05 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
>
> Indeed it is possible; NtQueryInformationFile with standard  
> information levels does translate into passthrough levels on the  
> wire (for SMB).
>
> But, as I mentioned, I am still working on the test code, and  
> haven't invoked NtSetInformationFile or other functions yet; I am  
> iterating on test cases to gather error return information (which is  
> a subject always dear to everyone's heart!). Of course, named pipes,  
> directories and the various flavors of junction points do complicate  
> this somewhat...
>
> 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: Wednesday, December 16, 2009 1:59 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
>
> Thank you for the update!  So if I understand what you're saying, it
> is possible for a windows app to cause the the smb client to send the
> passthrough levels over the wire using NtQueryInformationFile?
>
> -Tim
>
> On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote:
>
>> Good day Tim. I have just filed a Technical Documentation Issue
>> (TDI) against the share mode issue requesting document update /
>> guidance concerning SMB_INFO_PASSTHROUGH.
>>
>> My examination of our implementation indicates this situation should
>> exist for all SET_PATH_INFORMATION information levels with
>> SMB_INFO_PASSTHROUGH. I have not examined
>> TRANS2_SET_FILE_INFORMATION or TRANS2_SET_FS_INFORMATION.
>>
>> [MS-SMB] and [MS-FSCC] provide no guidance concerning share
>> circumvention for this or any other SMB_COM_TRANSACTION2
>> subcommand / information level with SMB_INFO_PASSTHROUGH, other than
>> to say 'the client is requesting a native Windows NT operating
>> system information level' ([MS-SMB] 6 Appendix A: Product Behavior,
>> note <155>).
>>
>> Also, I have nearly completed a test app (C++) to exercise these as
>> much as possible - NtQueryInformationFile indeed uses
>> SMB_INFO_PASSTHROUGH values. I intend to profile Windows behavior
>> against the information levels, and will provide all of that to you
>> as soon as I can.
>>
>> 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, December 09, 2009 10:56 AM
>> To: 'Tim Prouty'
>> Cc: pfif at tridgell.net; cifs-protocol at samba.org
>> Subject: RE: [Pfif] SMB1 Trans2SetPathInfo()
>> FileEndOfFileInformation is not enforcing share modes
>>
>> Tim, - thanks for the updated smbtorture. I have reproduced the
>> truncated SMB error response - see frames 132 & 133 in the attached
>> capture. I will create a new case for this, and begin debugging
>> today (after verifying whether or not this happens against older
>> Windows versions).
>>
>> Frame: Number = 133, Captured Frame Length = 102, MediaType =
>> ETHERNET
>> + Ethernet: Etype = Internet IP
>> + (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress:
>> [00-15-5D-
>> + 04-7B-09]
>> + Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP,
>> + Packet ID = 1552, Total IP Length = 88
>> + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152,
>> + PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510
>> + (scale factor 0x8) = 130560
>> + SMBOverTCP: Length = 32
>> - Smb: R - DOS OS Error, (124) INVALID_LEVEL
>>   Protocol: SMB
>>   Command: Transact2 50(0x32)
>> + DOSError: DOS OS Error - (124) INVALID_LEVEL
>> - SMBHeader: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID:
>> 0x0008
>>  + Flags: 136 (0x88)
>>  + Flags2: 34819 (0x8803)
>>    PIDHigh: 0 (0x0)
>>    SecuritySignature: 0x0
>>    Unused: 0 (0x0)
>>    TreeID: 2048 (0x800)
>>    ProcessID: 30665 (0x77C9)
>>    UserID: 2048 (0x800)
>>    MultiplexID: 8 (0x8)
>>
>> 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, December 08, 2009 12:55 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
>>
>> Thank you for your diligence on this Bill and the answers you have
>> provided.  I have some responses inline below.
>>
>> On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote:
>>
>>> 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.
>>
>>
>> I share the same sentiment as Zach on this behavior, but it is
>> definitely useful to know how windows handles this.  Are there plans
>> for this to be documented anywhere or does it receive documentation
>> exemption since this is passthrough-speceific?
>>
>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> = 
>>> ====================================================================
>>> 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.
>>
>>
>> I am interested to know the results of your testing.  I believe
>> there are some tests in RAW-OPLOCKS that use the rename passthrough
>> level to test oplocks, but implicitly rely on share modes not being
>> enforced for the rename passthrough.  RAW-OPLOCK-BATCH19, 20 and 21
>> are good ones to look at.
>>
>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> = 
>>> ====================================================================
>>> Question:
>>>
>>> 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)?
>>
>>
>> In comparing the pcaps, it does indeed appear that the version of
>> smbtorture you're running doesn't include the most recent version of
>> RAW-SFILEIFNO-END-OF-FILE.  Packet 54 in your trace corresponds to
>> packet 33 in my trace which is sending the SNIA CIFS EOF level
>> rather than the passthrough.  Packet 39 in my trace is the
>> setpathinfo EOF passthrough level that is actually getting the
>> strange error, and there is no corresponding packet in your trace.
>>
>> I'll get you the most recent code drop in a private channel.
>>
>> -Tim
>>
>