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. >> >
have_read.pcap
Description: application/vnd.tcpdump.pcap
no_read.pcap
Description: application/vnd.tcpdump.pcap
_______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
