[cifs-protocol] [REG:210052568854074001] - RE: NTCreateAndX with DesiredAccess of 0
Sebastian.Canevari at microsoft.com
Thu Jun 10 13:03:44 MDT 2010
Sorry for the delay in the response but in the course of our analysis we've discovered a couple extra details that needed attention and discussion before us being able to formulate a final answer.
There will be changes in the docs to better explain this behavior. I will let you know when those changes are ready and what exact docs and sections they will be available at.
As an advance to the final response, I would like to share with you that our code shows that we do the following operation with the DesiredAccess value at the SMB level:
DesiredAccess |= FILE_READ_ATTRIBUTES;
So, when the file system receives the request, the DesiredAccess will never be 0 and in that way we can query the file info after the open.
In case the DesiredAccess is greater than what it is allowed on that object, the return status from the underlying object store will be Status_Access_Denied.
I hope this provides you with a response to your question. However, as this is not 100% confirmed yet, I would advise you to rely only on my final response which I will share with you as soon as I have it in my hands.
Thanks and regards,
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: sebastc at microsoft.com
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of James Peach
Sent: Monday, May 24, 2010 11:08 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: [cifs-protocol] NTCreateAndX with DesiredAccess of 0
In MS-FSA 188.8.131.52, the initial parameter validation says that the operation MUST be failed with STATUS_INVALID_PARAMETER if DesiredAccess is zero. This may be true from the perspective of the object store, but it's not correct from the perspective of the SMB client.
The Mac OS X client implements the access(2) system call[*] by sending a SMB_COM_NT_CREATE_ANDX request with a DesiredAccess mask of zero. This causes the server to open a file handle with no access rights, but the SMB_COM_NT_CREATE_ANDX response returns the MaximalAccess which is what the client actually needs. This works with all the Windows versions that we have tested with. I believe that it works because the Windows SMB server implicitly opens the file with a non-zero DesiredAccess mask in order to obtain the necessary information for the SMB_COM_NT_CREATE_ANDX response. Note that providing any value for DesiredAccess might cause the request to fail with STATUS_ACCESS_DENIED, which will not provide the desired functionality.
I'm not sure whether MS-FSA should be updated, but it currently does not describe observable Windows behaviour in this regard.
cifs-protocol mailing list
cifs-protocol at cifs.org
More information about the cifs-protocol