[PATCH] test the effect of reordering ldb modify requests

[Douglas Bagnall]

Most ldb/ldap requests are agnostic with respect to the ordering of
their elements, with the request type ("ADD", "DELETE", etc) serving
as brutal instructions for all elements. But MODIFY requests are
different; they are more like scripts, with each element having its
own fate. The order of operations *should* make a difference. It is
easy to imagine logical outcomes for any given sequence of adds,
deletes and modifies, but this is AD so we have to test.

The test that considers every ordering permutation for a modify
request, and compares the answers against ground-truth gathered from
Windows 2012R2. The answers it receives from Samba are compared to the
ground truth and any difference is a failure.

For example, here is one of the shorter tests, for an object that
happens to be a user with a telephone. Three modify elements are tried
in all the possible orders (of which there are 3 * 2 * 1 == 6). The
elements are:

        mod_attrs = [("objectclass", "computer", FLAG_MOD_REPLACE),
                     ("objectclass", "user", FLAG_MOD_DELETE),
                     ("objectclass", "person", FLAG_MOD_DELETE)]

which have previously been run against Windows, with the answers
clustered by result, and serialised like so (in
source4/dsdb/tests/python/testdata/modify_order_objectclass.expected):

  modify_order_objectclass
  initial attrs:
           objectclass: 'user'
        otherTelephone: '123'
  == result ===[  2]=======================
           objectClass: [b'organizationalPerson', b'person', b'top', b'user']
        otherTelephone: [b'123']
  -- operations ---------------------------
       objectclass replace  computer
       objectclass delete   user
       objectclass delete   person
  ----------------------------------
       objectclass delete   user
       objectclass replace  computer
       objectclass delete   person
  ----------------------------------
  == result ===[  4]=======================
  ERR_OBJECT_CLASS_VIOLATION (65)
  -- operations ---------------------------
       objectclass replace  computer
       objectclass delete   person
       objectclass delete   user
  ----------------------------------
       objectclass delete   user
       objectclass delete   person
       objectclass replace  computer
  ----------------------------------
       objectclass delete   person
       objectclass replace  computer
       objectclass delete   user
  ----------------------------------
       objectclass delete   person
       objectclass delete   user
       objectclass replace  computer
  ----------------------------------

What it says is the two combinations ending with "delete person"
resulted in no change, and the other four resulted in an
OBJECT_CLASS_VIOLATION.

Then when we run it against Samba, we get a different result:

  modify_order_objectclass
  initial attrs:
           objectclass: 'user'
        otherTelephone: '123'
  == result ===[  2]=======================
           objectClass: [b'computer', b'organizationalPerson', b'person', b'top', b'user']
        otherTelephone: [b'123']
  -- operations ---------------------------
       objectclass delete   user
       objectclass delete   person
       objectclass replace  computer
  ----------------------------------
       objectclass delete   person
       objectclass delete   user
       objectclass replace  computer
  ----------------------------------
  == result ===[  2]=======================
           objectClass: [b'organizationalPerson', b'person', b'top', b'user']
        otherTelephone: [b'123']
  -- operations ---------------------------
       objectclass replace  computer
       objectclass delete   user
       objectclass delete   person
  ----------------------------------
       objectclass delete   user
       objectclass replace  computer
       objectclass delete   person
  ----------------------------------
  == result ===[  2]=======================
  ERR_OBJECT_CLASS_VIOLATION (65)
  -- operations ---------------------------
       objectclass replace  computer
       objectclass delete   person
       objectclass delete   user
  ----------------------------------
       objectclass delete   person
       objectclass replace  computer
       objectclass delete   user
  ----------------------------------


So that is a fail. Also, something of a mystery.

There is a pipeline running at

https://gitlab.com/samba-team/devel/samba/pipelines/57346326

and an earlier version passed here:

https://gitlab.com/samba-team/devel/samba/pipelines/56713222

What got me into this is a very slim hope I have that modify requests
might be semantically stable under a stable sort on attribute name
(e.g. like mergesort rather than quicksort). That would mean

   carLicense      MOD_A
   otherTelephone  MOD_B
   carLicense      MOD_C
   otherTelephone  MOD_D

is the same as

   carLicense      MOD_A
   carLicense      MOD_C
   otherTelephone  MOD_B
   otherTelephone  MOD_D

because each attribute gets the same sequence of modifications in
order. I haven't yet disproven the theory, but I expect to.

When run as a normal user, none of these modifications ever succeed
against either Windows or Samba, but we see different error code biota
on each.

Altogether the 26 tests provide 8 knownfails.

cheers,
Douglas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modify-reorder.patch
Type: text/x-patch
Size: 364592 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190418/e385524a/modify-reorder-0001.bin>