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.
>>
> 

Attachment: have_read.pcap
Description: application/vnd.tcpdump.pcap

Attachment: 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

Reply via email to