sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2024-12-23 17:34:34 +03:00
Code
10fd3e5836
samba-mirror/selftest/knownfail.d/smb2.replay

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

30 lines
1.7 KiB
Plaintext
Raw Normal View History

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-12 19:21:47 +03:00
# These tests demonstrate the broken Windows behavior
# and check for ACCESS_DENIED instead of FILE_NOT_AVAILABLE
# See https://bugzilla.samba.org/show_bug.cgi?id=14449
^samba3.smb2.replay.dhv2-pending1n-vs-violation-lease-close-windows.nt4_dc
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-12 17:10:46 +03:00
^samba3.smb2.replay.dhv2-pending1n-vs-violation-lease-ack-windows.nt4_dc
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-12 19:21:47 +03:00
^samba3.smb2.replay.dhv2-pending1n-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1n-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1l-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1l-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1o-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1o-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2n-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2n-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2l-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2l-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2o-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending2o-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3n-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3n-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3l-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3l-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3o-vs-oplock-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending3o-vs-lease-windows.nt4_dc
^samba3.smb2.replay.dhv2-pending1n-vs-oplock-windows.ad_dc
^samba3.smb2.replay.dhv2-pending1o-vs-oplock-windows.ad_dc
^samba3.smb2.replay.dhv2-pending2n-vs-oplock-windows.ad_dc
^samba3.smb2.replay.dhv2-pending2o-vs-oplock-windows.ad_dc
^samba3.smb2.replay.dhv2-pending3n-vs-oplock-windows.ad_dc
^samba3.smb2.replay.dhv2-pending3o-vs-oplock-windows.ad_dc
Copy Permalink