[cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission 
uri at samba.org
Thu Aug 4 08:28:21 UTC 2016
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.
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).
> 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 
> 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.
>> 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
>> 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 184.108.40.206, 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?
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 38825 bytes
Desc: not available
More information about the cifs-protocol