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.pro...@isilon.com] Sent: Wednesday, November 25, 2009 1:21 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@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 _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol