[cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]

Thu Aug 11 06:34:38 UTC 2016

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:uri at samba.org] 
> Sent: Thursday, August 4, 2016 3:28 AM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at 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:uri at samba.org]
>> Sent: Wednesday, August 3, 2016 6:55 AM
>> To: Obaid Farooqi <obaidf at microsoft.com>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>> <casemail at 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:uri at samba.org]
>>> Sent: Sunday, July 31, 2016 12:45 PM
>>> To: Interoperability Documentation Help <dochelp at microsoft.com>
>>> Cc: cifs-protocol at 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.
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: have_read.pcap
Type: application/vnd.tcpdump.pcap
Size: 13973 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20160811/e17a8e93/have_read-0001.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_read.pcap
Type: application/vnd.tcpdump.pcap
Size: 13922 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20160811/e17a8e93/no_read-0001.pcap>