Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote: Hi Bill, 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? Thanks! -Tim Here's the pcap referenced in the previous email. trans2setpathinfo_against_win7_2.pcap Description: Binary data ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Thanks! 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 01, 2009 12:34 PM To: Tim Prouty Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote: > Hi Bill, > > 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? > > Thanks! > > -Tim Here's the pcap referenced in the previous email. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
> 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? This is a surprise - I have never seen an SMB error packet without WordCount and ByteCount. I will take this into account once I get my test code running - which will be necessary to reproduce the missing WordCount / ByteCount (this looks like a bug to me, but I will have to dig deeper). 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 01, 2009 12:34 PM To: Tim Prouty Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote: > Hi Bill, > > 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? > > Thanks! > > -Tim Here's the pcap referenced in the previous email. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
On Dec 1, 2009, at 11:12 AM, Bill Wesse wrote: 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? This is a surprise - I have never seen an SMB error packet without WordCount and ByteCount. I will take this into account once I get my test code running - which will be necessary to reproduce the missing WordCount / ByteCount (this looks like a bug to me, but I will have to dig deeper). Bill, if it helps your repro I recently pushed an smbtorture test that demonstrates all of the issues mentioned in this thread: RAW-SFILEINFO- END-OF-FILE. This is what I have been using to produce these traces. -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Thanks - I have smbtorture up & working in an Ubuntu VM, so I should be able to test today. 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 01, 2009 7:40 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Dec 1, 2009, at 11:12 AM, Bill Wesse wrote: >> 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? > > This is a surprise - I have never seen an SMB error packet without > WordCount and ByteCount. > > I will take this into account once I get my test code running - > which will be necessary to reproduce the missing WordCount / > ByteCount (this looks like a bug to me, but I will have to dig > deeper). Bill, if it helps your repro I recently pushed an smbtorture test that demonstrates all of the issues mentioned in this thread: RAW-SFILEINFO- END-OF-FILE. This is what I have been using to produce these traces. -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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). Thanks for all your help with samba4/smbtorture (I am still having problems with gz on my Ubuntu client, so I unpacked it on my Windows client & cloned the tree to Ubuntu). No problems at all with the build. 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: Thursday, December 03, 2009 12:32 PM To: 'Tim Prouty' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Good morning Tim. I have successfully reproduced the share problem with Trans2SetPathInfo() FileEndOfFileInformation, using smbtorture (RAW-SFILEINFO-END-OF-FILE ) against both Windows 2008 R2 and Windows 7. This, of course, will allow me to dig deeper into the problem. Interestingly, 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 ); the only significant difference I see in the traces you sent and my test traces is that my Win7/R2 targets were using SmbSecuritySignatures (your Win7 client did not). I have attached my network captures (in both Wireshark tcp dump & Netmon 3.x format). I will retry with security signatures disabled and get back to you with the results. 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [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.pro...@isilon.com] Sent: Friday, December 04, 2009 12:20 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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: p...@tridgell.net; cifs-proto...@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 <
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
> -Original Message- > From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol- > boun...@cifs.org] On Behalf Of Bill Wesse > Sent: Tuesday, December 08, 2009 6:08 AM > To: Tim Prouty > Cc: p...@tridgell.net; cifs-proto...@samba.org > Subject: Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() > FileEndOfFileInformation is not enforcing share modes > > 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. [...] > #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. Thanks for the information on what a Windows server does. You should consider revisiting this decision, though, as it's a fairly serious data integrity issue. It's not just the file extension case that you need to consider - you're saying the client can *truncate* all of the data of the file without any share mode lock enforcement. ...Zach ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
I agree - truncating a file beneath an unshared open is not a good thing to happen. At this point, my goal is to document how the server works - and I am working on code to exercise the other information classes against SMB_INFO_PASSTHROUGH (one would hope, of course, that FileRenameInformation is rejected). Given the complexity of the SMB code, I will assume nothing. Once done, I will raise the issue internally as appropriate. 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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Tuesday, December 08, 2009 9:27 AM To: Bill Wesse; Tim Prouty Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes > -Original Message- > From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol- > boun...@cifs.org] On Behalf Of Bill Wesse > Sent: Tuesday, December 08, 2009 6:08 AM > To: Tim Prouty > Cc: p...@tridgell.net; cifs-proto...@samba.org > Subject: Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() > FileEndOfFileInformation is not enforcing share modes > > 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. [...] > #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. Thanks for the information on what a Windows server does. You should consider revisiting this decision, though, as it's a fairly serious data integrity issue. It's not just the file extension case that you need to consider - you're saying the client can *truncate* all of the data of the file without any share mode lock enforcement. ...Zach ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [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
Re: [cifs-protocol] [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'
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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 re
Re: [cifs-protocol] [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 perf
Re: [cifs-protocol] [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.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_C
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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: p...@tridgell.net; cifs-proto...@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.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) > +
Re: [cifs-protocol] [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: p...@tridgell.net; cifs-proto...@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.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 Err
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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:tim.pro...@isilon.com] Sent: Friday, December 18, 2009 2:07 PM To: Bill Wesse Cc: Zachary Loafman; p...@tridgell.net; cifs-proto...@samba.org 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: p...@tridgell.net; cifs-proto...@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.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- >> Fro
