Univention Bugzilla – Bug 45583
LDB module univention_samaccountname_ldap_check should directly assign official sambaSID
Last modified: 2021-11-12 12:15:20 CET
When an account is created at a UCS@school Slave ADDC the LDB Module univention_samaccountname_ldap_check should write the sambaSID allocated via UDM call directly into the objectSid field. Currently Samba first allocates an objectSid from its local RID Pool and then, a couple of seconds later the official sambaSID is replicated from the UCS Master to the Slave. This way we might end up with SID conflicts (objectSid index violation). To make this happen, the selectiveudm module needs to return the allocated sambaSID back to the LDB module first.
There is a draft for a patch in branch fbest/45583-create-computer-with-object-sid and some comments from Arvid: https://git.knut.univention.de/univention/ucs/commit/f57556d3f887024541d439034bd2586ffa705fb9#note_459
(In reply to Florian Best from comment #1) > There is a draft for a patch in branch > fbest/45583-create-computer-with-object-sid and some comments from Arvid: > https://git.knut.univention.de/univention/ucs/commit/ > f57556d3f887024541d439034bd2586ffa705fb9#note_459 The comments were lost due to gitlab garbage collection :-/ From my mails I can recover this one: Die manpage http://man7.org/linux/man-pages/man3/getline.3.html sagt, dass getline einen malloc'ed buffer erwartet und ggf auch realloc macht. Das hat zwei/drei Konsequenzen: getline hat kein Limit für die Anzahl der zu lesenden chars, d.h. char target_dn_str[SLAP_LDAPDN_MAXLEN+1] geht nicht. Grundsätzlich geht "char target_dn_str[]" vermutlich damit auch nicht, weil es ein array ist (auf dem stack) und kein pointer. Hier müsste man dann die Dekalaration und Initialisierung ändern auf "char *target_dn_str = NULL" (und vor dem zweiten getline wieder free aufrufen und len wieder auf 0 setzen). Die manpage sagt, dass der Anwender am Ende "free" auf den pointer machen muss. Wenn man getline verwendet, dann müsste man anschließend den buffer z.B. per talloc_strncpy in ein talloc-Objekt kopieren (konvertieren per talloc_reference funktionierte in einem kurzen Test leider nicht) und das talloc-Objekt an die Datenstruktur hängen von der es referenziert wird. Irgendwas in mir findes das zweifache allozieren und kopieren des strings unperformant, aber das ist vermutlich auch einfach egal. Ich würde mir wünschen, wenn man einen fixed size Buffer per talloc_size anlegen könnte und dann eine andere C-Funktion hätte, die diesen füllt. getline hat nur den nicen Vorteil, das Konzept einer Zeile zu kennen. Ein alternativer Ansatz wäre, per manuell per fgets aus fd[0] in vorallozierte talloc-buffer zu kopieren. Ist aber irgendwie auch hässlich. Eine kurze Google-Suche zeigt, dass die SID als String tendenziell eher 184 chars lang sein kann? object_sid_element->values = object_sid_val wird vermutlich direkt einen Segafault geben, weil object_sid_element nicht alloziert worden ist. Da sollte man mal in die Samba-Quellen hineinschauen, wie die das da üblicherweise machen. Wenn man in source4/dsdb/samdb/ldb_modules/samldb.c nach "objectSid must not be specified" sucht, dann sieht man, dass man das LDB_CONTROL_RELAX_OID-LDAP-Control aktiveren muss, damit samldb nicht mit der Fehlermeldung abbricht.
This issue has been filed against UCS@school 4.2. UCS@school 4.2 is out of maintenance and many UCS@school components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS@school versions, please reopen it and update the UCS@school version. In this case please provide detailed information on how this issue is affecting you.