s4:torture/smb2: make smb2.lock.replay_broken_windows more obvious
authorStefan Metzmacher <metze@samba.org>
Wed, 2 Oct 2019 12:51:26 +0000 (14:51 +0200)
committerJeremy Allison <jra@samba.org>
Sat, 27 Jun 2020 04:20:38 +0000 (04:20 +0000)
commit3b1b2e604669b481862219224843ee2e016a1f01
tree91b601c0d762f4c7e863d3535dc0dffed505fe91
parent6b6086bb58cf185145eeac99f146bf96b5311112
s4:torture/smb2: make smb2.lock.replay_broken_windows more obvious

This test checks the SMB 2.1.0 behaviour of lock sequence checking,
which is only turned on for resilient handles.

Even Windows Server 2019 only implements lock sequence checking only
for resilient and persistent handles as a server.
While its client side uses lock sequence checking if it negotiated
multichannel with the server.

Hopefully this will be fixed in future Windows versions.

Make it clear that this test is supposed to pass against the legacy
Windows servers which violate the specification:

  [MS-SMB2] 3.3.5.14 Receiving an SMB2 LOCK Request

  ...

  ... if Open.IsResilient or Open.IsDurable or Open.IsPersistent is
  TRUE or if Connection.Dialect belongs to the SMB 3.x dialect family
  and Connection.ServerCapabilities includes
  SMB2_GLOBAL_CAP_MULTI_CHANNEL bit, the server SHOULD<314>
  perform lock sequence verification ...

  ...

  <314> Section 3.3.5.14: Windows 7 and Windows Server 2008 R2 perform
  lock sequence verification only when Open.IsResilient is TRUE.
  Windows 8 through Windows 10 v1909 and Windows Server 2012 through
  Windows Server v1909 perform lock sequence verification only when
  Open.IsResilient or Open.IsPersistent is TRUE.

Note <314> also applies to all versions (at least) up to Windows Server v2004.

Hopefully this will be fixed in future Windows versions and they
will avoid Note <314>.

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
source4/torture/smb2/lock.c