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
