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.pro...@isilon.com] Sent: Wednesday, December 16, 2009 1:59 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@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: p...@tridgell.net; cifs-proto...@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.pro...@isilon.com] > Sent: Tuesday, December 08, 2009 12:55 PM > To: Bill Wesse > Cc: p...@tridgell.net; cifs-proto...@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 > _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol