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

[Bill Wesse]

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