[cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Tim Prouty]

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

On Nov 25, 2009, at 11:13 AM, Bill Wesse wrote:

>
> Question:
>
> Which existing handle would the pass-through be using?  The handle
> opened in packet #28 is a separate tcp connection and a separte
> session from the Trans2SetPathInfo in packet #33.  I'm not aware of
> any situation where the server is expected to share file handles
> across multiple sessions.  Is this an exception?
>
> Response:
>
> I was paying more attention to the PID (0x26CD) - and didn't drill  
> down closer to the sessions (both of which use the same security  
> principal). Thanks for pointing that out; I will take it into  
> account during my ongoing study (this implies a straight share mode  
> bypass).
>
> 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:
>
> That is certainly one of my goals - as I noted in my recent response  
> to Jeremy, I intend to set up test code to exercise the information  
> levels against the SMB calls.
>
> As I also mentioned, I will submit a TDI against this - before  
> starting on any test code.
>
> Also, the best reference for the full roster of info levels is at:
>
> MSDN WDF_FILE_INFORMATION_CLASS
> http://msdn.microsoft.com/en-us/library/dd568296.aspx
>
> this being a subset:
> [MS-FSCC] 2.4 File Information Classes
> http://msdn.microsoft.com/en-us/library/cc232064.aspx
>
> 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, November 25, 2009 1:21 PM
> To: Bill Wesse
> Cc: cifs-protocol at samba.org; pfif at tridgell.net
> Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is  
> not enforcing share modes
>
> Hi Bill,
>
> Thank you for the quick answer!  I have a few comments/questions  
> below.
>
> On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote:
>
>> Hello Tim. I think the difference in the response between the
>> standard versus pass-through level lies in how the file handle is
>> obtained during the call (given that TRANS2_SET_PATH_INFORMATION
>> passes the path, and not the handle). The logical conclusion from
>> the trace is that pass-through gets the existing handle, and the non
>> pass-through value simply fails, because a new handle cannot be
>> opened due to the lack of sharing.
>
>
> Which existing handle would the pass-through be using?  The handle
> opened in packet #28 is a separate tcp connection and a separte
> session from the Trans2SetPathInfo in packet #33.  I'm not aware of
> any situation where the server is expected to share file handles
> across multiple sessions.  Is this an exception?
>
>
>> I will continue my investigation into the details on the differences
>> between the base & pass-through handling, with respect to the file
>> path / handle source. Pass-through is basically implementation
>> dependent, as noted in [MS-FSCC] (reference below), so there is a
>> possibility this may not be further elaborated on in the documents.
>
>
> 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?).
>
>
>> Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a
>> pass-through value), since that requires the file handle (per [MS-
>> CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx)
>> .
>
>
> I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the
> same session would have succeeded.
>
> -Tim