[cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Bill Wesse
billwe at microsoft.com
Fri Dec 18 06:38:46 MST 2009
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: pfif at tridgell.net; cifs-protocol at 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.prouty at isilon.com]
Sent: Wednesday, December 16, 2009 1:59 PM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Thank you for the update! So if I understand what you're saying, it
is possible for a windows app to cause the the smb client to send the
passthrough levels over the wire using NtQueryInformationFile?
-Tim
On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote:
> Good day Tim. I have just filed a Technical Documentation Issue
> (TDI) against the share mode issue requesting document update /
> guidance concerning SMB_INFO_PASSTHROUGH.
>
> My examination of our implementation indicates this situation should
> exist for all SET_PATH_INFORMATION information levels with
> SMB_INFO_PASSTHROUGH. I have not examined
> TRANS2_SET_FILE_INFORMATION or TRANS2_SET_FS_INFORMATION.
>
> [MS-SMB] and [MS-FSCC] provide no guidance concerning share
> circumvention for this or any other SMB_COM_TRANSACTION2
> subcommand / information level with SMB_INFO_PASSTHROUGH, other than
> to say 'the client is requesting a native Windows NT operating
> system information level' ([MS-SMB] 6 Appendix A: Product Behavior,
> note <155>).
>
> Also, I have nearly completed a test app (C++) to exercise these as
> much as possible - NtQueryInformationFile indeed uses
> SMB_INFO_PASSTHROUGH values. I intend to profile Windows behavior
> against the information levels, and will provide all of that to you
> as soon as I can.
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
> -----Original Message-----
> From: Bill Wesse
> Sent: Wednesday, December 09, 2009 10:56 AM
> To: 'Tim Prouty'
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: [Pfif] SMB1 Trans2SetPathInfo()
> FileEndOfFileInformation is not enforcing share modes
>
> Tim, - thanks for the updated smbtorture. I have reproduced the
> truncated SMB error response - see frames 132 & 133 in the attached
> capture. I will create a new case for this, and begin debugging
> today (after verifying whether or not this happens against older
> Windows versions).
>
> Frame: Number = 133, Captured Frame Length = 102, MediaType =
> ETHERNET
> + Ethernet: Etype = Internet IP
> + (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress:
> [00-15-5D-
> + 04-7B-09]
> + Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP,
> + Packet ID = 1552, Total IP Length = 88
> + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152,
> + PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510
> + (scale factor 0x8) = 130560
> + SMBOverTCP: Length = 32
> - Smb: R - DOS OS Error, (124) INVALID_LEVEL
> Protocol: SMB
> Command: Transact2 50(0x32)
> + DOSError: DOS OS Error - (124) INVALID_LEVEL
> - SMBHeader: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID:
> 0x0008
> + Flags: 136 (0x88)
> + Flags2: 34819 (0x8803)
> PIDHigh: 0 (0x0)
> SecuritySignature: 0x0
> Unused: 0 (0x0)
> TreeID: 2048 (0x800)
> ProcessID: 30665 (0x77C9)
> UserID: 2048 (0x800)
> MultiplexID: 8 (0x8)
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
>
> -----Original Message-----
> From: Tim Prouty [mailto:tim.prouty at isilon.com]
> Sent: Tuesday, December 08, 2009 12:55 PM
> To: Bill Wesse
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: Re: [Pfif] SMB1 Trans2SetPathInfo()
> FileEndOfFileInformation is not enforcing share modes
>
> Thank you for your diligence on this Bill and the answers you have
> provided. I have some responses inline below.
>
> On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote:
>
>> Is #3 actually correct behavior that other servers should implement?
>> If so, can the cases where share modes are not enforced be enumerated
>> in the documentation?
>>
>> Response:
>>
>> #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for
>> SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH +
>> FileEndOfFileInformation is functionally equivalent to a remote call
>> to NtSetInformationFile.
>>
>> NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the
>> file system driver in question; this does not involve the usual I/O
>> Manager ShareMode checks.
>
>
> I share the same sentiment as Zach on this behavior, but it is
> definitely useful to know how windows handles this. Are there plans
> for this to be documented anywhere or does it receive documentation
> exemption since this is passthrough-speceific?
>
>
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> Question:
>>
>> If a client can send a particular info level and windows implements
>> it, then we have a compatibility problem if we choose not to support
>> it. What I would really like to know is if other SMB implementations
>> need to circumvent share-mode checks for this pass through level (and
>> maybe others?).
>>
>> Response:
>>
>> This should be the case for all supported SMB_INFO_PASSTHROUGH
>> levels,
>> as they run through the same essential logic.
>>
>> However, I have additional testing to perform before I can completely
>> confirm this.
>
>
> I am interested to know the results of your testing. I believe
> there are some tests in RAW-OPLOCKS that use the rename passthrough
> level to test oplocks, but implicitly rely on share modes not being
> enforced for the rename passthrough. RAW-OPLOCK-BATCH19, 20 and 21
> are good ones to look at.
>
>
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> Question:
>>
>> 1. Packet 40 appears to have the WordCount and ByteCount truncated,
>> making the packet smaller than normal minimum size of 35? Is this
>> intended behavior that other servers should implement?
>>
>> Additionally a DOS Error is returned instead of a standard NT_STATUS
>> error. MS-CIFS does say that a DOS error or an NT_STATUS error may
>> be
>> returned, but I don't see any indication in the documentation of when
>> a DOS error should be returned instead of an NT_STATUS error. Is it
>> possible to make this explicit in the docs or is this a case where
>> it's purposefully left ambiguous?
>>
>> Response:
>>
>> The WordCount/ByteCount truncation against the Dos INVALID_LEVEL
>> error
>> problem
>> (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce
>> with
>> my clients (who succeeded against the call).
>>
>> I have attached a zip file with your trace
>> (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace
>> (test_trans2setpathinfo_Win7.pcap). Mine does not have that second
>> Set
>> EOF call. Do I need a newer build of smbtorture (my current one from
>> you is samba.2009.12.01.tar.gz)?
>
>
> In comparing the pcaps, it does indeed appear that the version of
> smbtorture you're running doesn't include the most recent version of
> RAW-SFILEIFNO-END-OF-FILE. Packet 54 in your trace corresponds to
> packet 33 in my trace which is sending the SNIA CIFS EOF level
> rather than the passthrough. Packet 39 in my trace is the
> setpathinfo EOF passthrough level that is actually getting the
> strange error, and there is no corresponding packet in your trace.
>
> I'll get you the most recent code drop in a private channel.
>
> -Tim
>
More information about the cifs-protocol
mailing list