Hi Obaid, I (hopefully) did as requested. I'd like to thank you for bearing with me on this one, this is much appreciated.
Thanks, Uri. On 08/11/2016 09:33 PM, Obaid Farooqi wrote: > Hi Uri: > You must have received an email about creation of a workspace with > credentials to login. Please download the t.cmd file from there and copy it > to your Windows SMB server that you are using for this testing and follow the > steps below to collect and send me the traces. > > 1. Open an elevated command prompt and cd to the directory where you copied > t.cmd. For illustration I'll assume you copied it in c:\etw directory. > > 2. cd to c:\etw and execute the following command: > C:\etw> t.cmd srvon > 3. start a network capture > 4. reproduce the copychunk error > 5. Once done with error reproduction, execute the following command in the > same window you opened in step 1. > C:\etw>t.cmd srvoff > The above command will take couple of minutes to run and will create a file > whose name starts with t and has extension .cab > 6. stop network capture and save it. > 7. upload the cab file and network capture to the work space where you down > loaded the t.cmd file and let me know. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at ramagane at > Microsoft dot com > > -----Original Message----- > From: Uri Simchoni [mailto:u...@samba.org] > Sent: Thursday, August 11, 2016 1:35 AM > To: Obaid Farooqi <oba...@microsoft.com> > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email <casem...@microsoft.com> > Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission > [116073114482785] > > Hi Obaid, > > I'm still confused about the copychunk behavior. > > Let me reiterate what I understand, and then try to explain what I don't > understand. > > 1. At the time of open, if the desired access included FILE_EXECUTE, then an > SMB2 server would add FILE_READ_DATA to the granted access rights - this bit > needs to be added to [MS-SMB2]. > > 2. COPYCHUNK: The only two restrictions mentioned about the dest handle are: > a. that it must have FILE_READ_DATA access, b. that it must have either > FILE_WRITE_DATA or FILE_APPEND_DATA, or both. > > 3. Combining the two together would imply that if we open the dest handle > with FILE_EXECUTE | FILE_WRITE_DATA, then we'll be implicitly granted > FILE_READ_DATA, and the copychunk would succeed. > > 4. Yet (and here's the part I don't understand), when trying the last thing, > the copychunk fails with access-denied. > > You mentioned that there might be other reasons within the object store to > reject the copychunk in this case. That's a case where the object store > affects the observed behavior, and if at all possible I would like to > understand the source of the object store's rejection of the copy, even if it > falls outside MS-SMB2 (e.g. maybe it belongs in MS-FSA). > > I tried to be more prudent this time, and in the attached packet captures, > the only difference between the successful copychunk in have_read.pcap and > the failed one in no_read.pcap, is that the dest handle in the failed attempt > was created without FILE_READ_DATA in the desired access. However, since it > did have FILE_EXECUTE, I would expect that internally it would be granted > FILE_READ_DATA, and the copy to succeed. > > Thanks, > Uri. > > On 08/11/2016 12:43 AM, Obaid Farooqi wrote: >> Hi Uri: >> For object store on Windows, the execute permissions means read access >> is automatic. The execute permission is called "Read&Execute" as noted >> here https://msdn.microsoft.com/en-us/library/bb727008.aspx >> The SMB server does extra permission checking as would be done by IO manager >> if the operation were local. So I can clearly see that the read permission >> is allowed at the time of create in the code and no additional permissions >> are asked for at the time of read. >> >> As for the copychunk issue, the server is behaving as documented. So from >> the standpoint of protocol document, there is nothing to do. >> >> I looked in the code for what you are describing and see that for copy >> chunk, server checks for write and append permissions for target and return >> access denied if that condition is not met. So the error, it appears, is >> bubbling from object store. >> If you want me to investigate further, I'll need some server side traces >> from you. If yes, then let me know and I'll send you a tool to collect the >> traces and also create a workspace where you can upload the resultant traces. >> >> Please let me know if it does not answer your question. >> Also please let me know if you have any additional questions. >> >> Regards, >> Obaid Farooqi >> Escalation Engineer | Microsoft >> >> Exceeding your expectations is my highest priority. If you would like >> to provide feedback on your case you may contact my manager at >> ramagane at Microsoft dot com >> >> -----Original Message----- >> From: Uri Simchoni [mailto:u...@samba.org] >> Sent: Thursday, August 4, 2016 3:28 AM >> To: Obaid Farooqi <oba...@microsoft.com> >> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email >> <casem...@microsoft.com> >> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission >> [116073114482785] >> >> Hi Obaid, >> >> That description implies that FILE_READ_DATA is granted at open time (NOT on >> read time). To test that, I tested what happens with another operation - >> COPYCHUNK, and got some confusing results. >> >> It seems that with COPYCHUNK, having FILE_EXECUTE on the *source* handle >> would allow the copy, but having FILE_EXECUTE on the *destination* handle >> (which also requires FILE_READ_DATA right) would not allow the copy. >> >> See attached (made against Server2012R2) - the first two attempts test the >> source handle. Both are successful - one with FILE_READ_DATA and one without >> FILE_READ_DATA but with FILE_EXECUTE. The next two attempts test the dest >> handle, and the one without FILE_READ_DATA but with FILE_EXECUTE instead - >> fails. >> >> Can you please clarify? >> >> My testing also confirms that SMB1 wouldn't let you do the same - it has >> read_for_execute bit in the read request for that purpose. >> >> Thanks, >> Uri >> >> On 08/04/2016 01:13 AM, Obaid Farooqi wrote: >>> Hi Uri: >>> My research shows that Windows SMB2 Servers (Vista/WS2008 and onwards) add >>> FILE_READ_DATA to Open.GrantedAccess after file is opened and FILE_EXECUTE >>> is granted by the object store. >>> >>> I did not find a similar pattern in the smb1 source. If you find otherwise, >>> please let us know. >>> >>> I have filed a bug against MS-SMB2 document to include this behavior. >>> >>> Please let me know if this does not answer your question. >>> Also please let me know if you have any further question(s). >>> >>> Regards, >>> Obaid Farooqi >>> Escalation Engineer | Microsoft >>> >>> Exceeding your expectations is my highest priority. If you would >>> like to provide feedback on your case you may contact my manager at >>> ramagane at Microsoft dot com >>> >>> -----Original Message----- >>> From: Uri Simchoni [mailto:u...@samba.org] >>> Sent: Wednesday, August 3, 2016 6:55 AM >>> To: Obaid Farooqi <oba...@microsoft.com> >>> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email >>> <casem...@microsoft.com> >>> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission >>> [116073114482785] >>> >>> On 08/01/2016 01:41 AM, Obaid Farooqi wrote: >>>> Hi Uri: >>>> Thanks for contacting Microsoft. I have created a case to track this >>>> issue. A member of the open specifications team will be in touch soon. >>>> >>>> Regards, >>>> Obaid Farooqi >>>> Escalation Engineer | Microsoft >>>> >>>> Exceeding your expectations is my highest priority. If you would >>>> like to provide feedback on your case you may contact my manager at >>>> ramagane at Microsoft dot com >>>> >>>> -----Original Message----- >>>> From: Uri Simchoni [mailto:u...@samba.org] >>>> Sent: Sunday, July 31, 2016 12:45 PM >>>> To: Interoperability Documentation Help <doch...@microsoft.com> >>>> Cc: cifs-protocol@lists.samba.org >>>> Subject: [MS-SMB2] allow read based on FILE_EXECUTE permission >>>> >>>> Hi, >>>> >>>> This question concerns the right to read from a file opened with >>>> FILE_EXECUTE but without FILE_READ_DATA in the desired access mask. >>>> >>>> According to [MS-SMB2] section section 3.3.5.12, about how to process a >>>> READ request: >>>> >>>> If Open.GrantedAccess does not allow for FILE_READ_DATA, the request MUST >>>> be failed with STATUS_ACCESS_DENIED. >>>> >>>> However, testing against Windows Server 2012R2 shows that if >>>> FILE_EXECUTE is granted instead of FILE_READ_DATA, the read is also >>>> allowed (I suppose this has to do with running executables...) >>>> >>>> The attached tcpdump packet trace demonstrates that - in packet 22, EOF is >>>> returned instead of ACCESS_DENIED. >>>> >>>> Can you please clarify? >>>> >>>> Thanks, >>>> Uri. >>>> >>> >>> The packet capture I originally attached was by (modified) smbtorture >>> command. However the real use case where we see this is when loading a >>> driver from a remote share: >>> 1. samba ad member server joined to domain and client joined 2. put a >>> driver file on a share and give everyone full control 3. run the following >>> from elevated command prompt: >>> sc create mydriver type=kernel start=demand error=normal >>> binpath=\\my-server.my-domain.local\my-share\mydriver.sys >>> sc start mydriver >>> >>> That would generate the "open for execute and read" pattern. >>> >>> Thanks, >>> Uri. >>> >> > _______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
