Hello Volker, Based on test results and some verification, we have found that some command groups (e.g. session management) in general do not enforce change in the latest security token in the session while others ( e.g. Transaction sub-protocol commands) do enforce latest security token resulting from the re-authentication operation performed. Below is a representative list of commands from the two categories described. Please note that because of the effort involved in testing/cross checking with spec, this is not a complete list of every SMB command. If you have any follow up questions please let us know. For instance if a specific list of commands you are interested in are not listed here and you want to know specifically how they work, do not hesitate to reply to this e-mail with that list. Also for obsolete commands, would you still be interested in how security is applied for those ?
Category A: Commands that use latest security token associated with session resulting from re-authentication SMB_COM_CREATE_DIRECTORY SMB_COM_OPEN SMB_COM_OPEN_ANDX SMB_COM_CREATE SMB_COM_CREATE_NEW SMB_COM_CREATE_TEMPORARY SMB_COM_NT_CREATE_ANDX SMB_COM_RENAME SMB_COM_NT_RENAME SMB_COM_QUERY_INFORMATION SMB_COM_SET_INFORMATION SMB_COM_OPEN_PRINT_FILE SMB_COM_IOCTL SMB_COM_CHECK_DIRECTORY SMB_COM_SEARCH Category B: Commands that don't enforce latest security token resulting from re-authentication SMB_COM_LOCKING_ANDX SMB_COM_READ_ANDX SMB_COM_WRITE_ANDX SMB_COM_NEGOTIATE SMB_COM_SESSION_SETUP_ANDX SMB_COM_TREE_CONNECT SMB_COM_TREE_CONNECT_ANDX SMB_COM_TREE_DISCONNECT SMB_COM_CLOSE SMB_COM_FLUSH SMB_COM_QUERY_INFORMATION2 In addition to this, FSA document described the STATUS_ACCESS_DENIED error seen from your test results 3.1.5.13 Server Requests a Query of Security Information § The operation MUST be failed with STATUS_ACCESS_DENIED under either of the following conditions: § SecurityInformation contains any of OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, LABEL_SECURITY_INFORMATION, or DACL_SECURITY_INFORMATION, and Open.GrantedAccess does not contain READ_CONTROL. Also in SMB1, if CAP_EXTENDED_SECURITY is NOT set and we perform a re-authentication, UID/session will change. This change itself may cause an operation to fail simply because an FID would be invalid for the new session. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications -----Original Message----- From: Volker Lendecke [mailto:volker.lende...@sernet.de] Sent: Monday, August 06, 2012 9:22 AM To: Sreekanth Nadendla Cc: MSSolve Case Email; cifs-protocol@cifs.org; p...@tridgell.net Subject: Re: 112050346749387 handle based permission checks in SMB1? On Thu, May 24, 2012 at 09:29:12PM +0000, Sreekanth Nadendla wrote: > Hello Volker, > Our product group is investigating this issue closely. I will provide > you an update as soon as we conclude our review. Thank you for being > patient. Do you have any updates on this matter? Thanks, Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kont...@sernet.de _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol