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

Reply via email to