3 Commits

Author	SHA1	Message	Date
Stefan Metzmacher	f0e5537834	smb2_server: don't cancel pending request if at least one channel is still alive ... In order to allow replays of requests on a channel failure, we should not cancel pending requests, the strategie that seems to make windows clients happy is to let the requests running and return NT_STATUS_FILE_NOT_AVAILABLE as long as the original request is still pending. Here we introduce xconn->transport.shutdown_wait_queue, this is used to keep the xconn alive for the lifetime of pending requests. Now we only cancel pending requests if the disconnected connection is the last channel for a session. In that case smbXsrv_session_remove_channel() and smb2srv_session_shutdown_send() will take care of it. BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>	2021-03-29 19:36:37 +00:00
Stefan Metzmacher	997e9023c0	smbXsrv_open: intruduce smbXsrv_open_replay_cache to support FILE_NOT_AVAILABLE ... Before processing an open we need to reserve the replay cache entry in order to signal that we're still in progress. If a reserved record is already present we need to return FILE_NOT_AVAILABLE in order to let the client retry again. [MS-SMB2] contains this: <152> Section 3.2.5.1: For the following error codes, Windows-based clients will retry the operation up to three times and then retry the operation every 5 seconds until the count of milliseconds specified by Open.ResilientTimeout is exceeded: - STATUS_SERVER_UNAVAILABLE - STATUS_FILE_NOT_AVAILABLE - STATUS_SHARE_UNAVAILABLE This works fine for windows clients, but current windows servers seems to return ACCESS_DENIED instead of FILE_NOT_AVAILABLE. A Windows server doesn't do any replay detection on pending opens, which wait for a HANDLE lease to be broken (because of a SHARING_VIOLATION), at all. As this is not really documented for the server part of the current [MS-SMB2], I found the key hint in "SMB 2.2: Bigger. Faster. Scalier - (Parts 1 and 2)" on page 24. There's a picture showing that a replay gets FILE_NOT_AVAILABLE as long as the original request is still in progress. See: https://www.snia.org/educational-library/smb-22-bigger-faster-scalier-parts-1-and-2-2011 A Windows client is unhappy with the current windows server behavior if it such a situation happens. There's also a very strange interaction with oplock where the replay gets SHARING_VIOLATION after 35 seconds because it conflicts with the original open. I think it's good to follow the intial design from the 2011 presentation and make the clients happy by using FILE_NOT_AVAILABLE (and differ from Windows). I'll report that to dochelp@microsoft.com in order to get this hopefully fixed in their server too). BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>	2021-03-29 19:36:37 +00:00
Stefan Metzmacher	f5168a21ab	s4:torture/smb2: add smb2.replay.dhv2-pending* tests ... These demonstrate that the replay detection for pending opens either doesn't exist (for the share_access=NONE => SHARING_VIOLATION case) or return the wrong status code => ACCESS_DENIED instead of FILE_NOT_AVAILABLE. Windows clients transparently retry after FILE_NOT_AVAILABLE, while they pass ACCESS_DENIED directly to the application. I'll report that to dochelp@microsoft.com in order to clarify the situation. In the meantime I added tests with a '-windows' suffix, which demostrate the current windows server behavior, while the tests with a '-sane' suffix expect the behavior that whould make windows clients happy. For Samba I'll implement the '-sane' behavior that detects all replays and returns FILE_NOT_AVAILABLE if the original request is still pending. BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>	2021-03-29 19:36:37 +00:00