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 rely on share modes not being enforced for
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
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_COM_TRANSACTION2 request for SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation is
