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

Wed Dec 16 12:04:53 MST 2009

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
>