Bug 41900 - modify after remove corrupts pickle file when moving to a non readable location (part2)
modify after remove corrupts pickle file when moving to a non readable locati...
Product: UCS@school
Classification: Unclassified
Component: ucs-test
UCS@school 4.1 R2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS@school maintainers
Depends on: 32542 41884
  Show dependency treegraph
Reported: 2016-08-03 06:05 CEST by Stefan Gohmann
Modified: 2019-02-05 21:43 CET (History)
4 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2016-08-03 06:05:00 CEST
Since the problem is reproducible in school environments, we should add a test case for it.

+++ This bug was initially created as a clone of Bug #41884 +++

The fix of bug #32542 introduced a similar problem.

Following scenario:
Object A is moved within LDAP from position X to position Y. Afterwards object B is modified. Due to LDAP ACLs the local system has no access rights for position Y and therefore only the first of the 2 modrdn actions is passed to the handler() method.

The s4-connector.py handles action "r" of object A and created a pickle file of A.dn and A.old. The following action "a" of object A is omitted due to the LDAP access rights. When object B is modified, handler() loads the pickle file and compares the entryUUID of the pickle data and the current data → the entryUUIDs differ, so the handler() method creates a new pickle file for the S4 connector  
that should contain a "delete" action of object A.

But the s4-pickle file written contains A.dn and B.old. This causes some trouble later on in the S4 connector. The entryUUID of B will be added to the "UCS deleted" sqlite table (even if the object B has not been removed). All further changes to object B are therefore no longer synced to Samba4.

(In reply to Felix Botner from Bug 32542 comment #6)
> 07.10.13 09:58:17.884  LISTENER    ( ERROR   ) : import of
> filename=/usr/lib/univention-directory-listener/system/s4-connector.py failed
>   File "/usr/lib/univention-directory-listener/system/s4-connector.py", line
> 143
>     _dump_changes_to_file_and_check_file(directory, dn, new, old, old_dn)

This line should be 
_dump_changes_to_file_and_check_file(directory, dn, new, old_object, old_dn)

+++ This bug was initially created as a clone of Bug #32542 +++

If moving a windows client from cn=computers,$ldap_base to cn=computers,cn=schoolou,$ldap_base every school slave which cannot read this schoolou creates the Group "Windows Hosts" in s4 instead.

5607 cn=windowskaputt,cn=computers,dc=schoolmulti-s4,dc=qa r
5608 cn=windowskaputt,cn=computers,ou=schule2,dc=schoolmulti-s4,dc=qa a
5609 cn=Windows Hosts,cn=groups,dc=schoolmulti-s4,dc=qa m #(normal membership update)

The pickle file loads itself with 5607 as old_dn (because of the actiontype "r") - it expects the "a" action now, but never "sees" 5608 (selective replication in UCS@School). Instead it uses 5609 and the following happens in the connector:

"move group from [cn=windowskaputt,cn=computers,dc=schoolmulti-s4,dc=qa] to [cn=Windows Hosts,cn=groups,dc=schoolmulti-s4,dc=qa]"

The attached patch prevents this.
This is totally untested for other operations and should only concrete the behaviour a bit more.
Comment 1 Florian Best univentionstaff 2017-06-28 14:56:51 CEST
There is a Customer ID set so I set the flag "School Customer affected".
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2019-02-05 21:43:41 CET
This issue has been filled against UCS@school 4.1 (R2). The maintenance with
bug and security fixes for UCS@school 4.1 (R2) has ended on 5th of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3 (or later). 
Please contact your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug"
or simply reopen the issue. In this case please provide detailed information on
how this issue is affecting you.