My pleasure - this was - and is - a very interesting topic! By the way, I will be continuing my study of SMB_INFO_PASSTHROUGH and the Nt*Info calls. I expect to post a blog entry on the 'Microsoft Open Specification Support Team Blog' (http://blogs.msdn.com/OpenSpecification/) sometime in January.
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:[email protected]] Sent: Friday, December 18, 2009 2:07 PM To: Bill Wesse Cc: Zachary Loafman; [email protected]; [email protected] Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes 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: [email protected]; [email protected] > 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:[email protected]] > Sent: Wednesday, December 16, 2009 1:59 PM > To: Bill Wesse > Cc: [email protected]; [email protected] > 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: [email protected]; [email protected] >> 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:[email protected]] >> Sent: Tuesday, December 08, 2009 12:55 PM >> To: Bill Wesse >> Cc: [email protected]; [email protected] >> 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 >> > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
