Univention Bugzilla – Bug 15841
deleteObjectClass=1 wird beim Modifizieren nicht respektiert
Last modified: 2018-04-13 13:29:28 CEST
Getestet auf 2.2-2: Die benutzerdefinierte Objektklasse univentionFreeAttributes wird sowohl bei customattributes als auch bei extendedattributes nicht von Ldap-Objekten entfernt, nachdem bei diesen das custom- bzw. extended-attribut mittels remove entfernt wurde. Wird kein Wert für das custom- bzw. extendedattribut beim Anlegen des Objekts gesetzt, so hat das Objekt auch nicht die Objektklasse univentionFreeAttributes. Repro für customattributes: root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'settings/customattribute' create --position "cn=custom attributes,cn=univention,dc=univention,dc=test" --set 'name'='taunxeni' --set 'module'='computers/managedclient' --set 'shortDescription'='Test Short Description' --set 'objectClass'='univentionFreeAttributes' --set 'deleteObjectClass'='1' --set 'ldapMapping'='univentionFreeAttribute7' root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'computers/managedclient' create --position "cn=computers,dc=univention,dc=test" --set 'name'='akzlplmx' --customattribute "Test Short Description"="foo" root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# ldapsearch -xLLL -b 'cn=vdrgqkex,cn=computers,dc=univention,dc=test' 'objectClass' dn: cn=vdrgqkex,cn=computers,dc=univention,dc=test objectClass: top objectClass: person objectClass: univentionHost objectClass: univentionClient objectClass: krb5Principal objectClass: krb5KDCEntry objectClass: posixAccount objectClass: shadowAccount objectClass: univentionFreeAttributes root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'computers/managedclient' modify --dn "cn=vdrgqkex,cn=computers,dc=univention,dc=test" --customattribute-remove "Test Short Description"="foo" root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# ldapsearch -xLLL -b 'cn=vwhvbkcz,cn=computers,dc=univention,dc=test' 'objectClass' dn: cn=vwhvbkcz,cn=computers,dc=univention,dc=test objectClass: top objectClass: person objectClass: univentionHost objectClass: univentionClient objectClass: krb5Principal objectClass: krb5KDCEntry objectClass: posixAccount objectClass: shadowAccount objectClass: univentionFreeAttributes Analog für extended-attributes (ohne ldapsearch): root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'settings/extended_attribute' create --position "cn=custom attributes,cn=univention,dc=univention,dc=test" --set 'name'='chkwfhar' --set 'shortDescription'='Test Short Description' --set 'CLIName'='fbwdhsxr' --set 'module'='computers/managedclient' --set 'mayChange'='1' --set 'objectClass'='univentionFreeAttributes' --set 'ldapMapping'='univentionFreeAttribute7' --set 'deleteObjectClass'='1' root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'computers/managedclient' create --position "cn=computers,dc=univention,dc=test" --set 'name'='dgnhnids' --set fbwdhsxr="foo" root@master22:/usr/share/ucs-test/scripts/69_udm_customattribute# univention-directory-manager 'computers/managedclient' modify --dn "cn=dgnhnids,cn=computers,dc=univention,dc=test" --remove fbwdhsxr="foo"
Testfälle 60_delete_object_class in den Paketen ucs-test-udm-customattributes bzw. ucs-test-udm-extendedattributes hinzugefügt.
Erneut aufgetreten: Ticket #2010102910000505
Verhält sich in UCS 3.0 für settings/extended_attribute ebenfalls noch so: -> udm users/user modify --dn "uid=test4,cn=users,dc=w2k3,dc=r2" --set dienstwagen=aa -> univention-ldapsearch uid=test4 ... objectClass: univentionFreeAttributes univentionFreeAttribute1: aa ... -> udm users/user modify --dn "uid=test4,cn=users,dc=w2k3,dc=r2" --set dienstwagen="" -> univention-ldapsearch uid=test4 ... objectClass: univentionFreeAttributes ... -> udm settings/extended_attribute list DN: cn=dienstwagen-ext,cn=custom attributes,cn=univention,dc=w2k3,dc=r2 ARG: None objectClass: univentionFreeAttributes groupPosition: None module: users/user overwritePosition: None hook: None overwriteTab: None shortDescription: Kennzeichen des Dienstwagen groupName: None version: 2 valueRequired: None CLIName: dienstwagen fullWidth: None longDescription: Kennzeichen des Dienstfahrzeugs doNotSearch: None tabName: Dienstfahrzeug syntax: None tabAdvanced: None name: dienstwagen-ext default: None mayChange: 1 multivalue: None ldapMapping: univentionFreeAttribute1 deleteObjectClass: 1 notEditable: 0 options: None tabPosition: 2
*** Bug 5579 has been marked as a duplicate of this bug. ***
The code for removing the objectClass only seems to wok with boolean attributes. The code for handling the objectClass removal is too naive: 1. an attribute may be allowed by more than one objectClass 2. an attribute may be a MAY attribute in one objectClass and a MUST attribute in some other 3. removing one objectClass may require the removal of other attributes too Basically UDM would need to have its own LDAP-Schema-Parser to do something like the following: 1. If an attribute with deleteObjectClass=1 is removed, test-wise remove the objectClass (OC) from the list of OCs. 2. Determine the remaining OCs. 3. Determine the set of still allowed MUST and MAY attributes. 4. Validate that the remaining UDM properties are covered by that set. 5. Only then permanently remove the OC by adding it to the mod_list. 6. Otherwise the OC can't be deleted as its removal would invalidate the LDAP object.
(In reply to Philipp Hahn from comment #5) > The code for removing the objectClass only seems to wok with boolean > attributes. > The code for handling the objectClass removal is too naive: > 1. an attribute may be allowed by more than one objectClass > 2. an attribute may be a MAY attribute in one objectClass and a MUST > attribute in some other > 3. removing one objectClass may require the removal of other attributes too In general, this is used by custom LDAP schema extensions. Therefore, I imagine that we could simplify this by postulating certain assumptions, e.g., that the attribute will only belong to the specific objectClass.
What is the consequence if you just try to remove the objectClass? I see the following cases: a) it is possible: UMC/UDM works a expected, users are happy :-)) b) it is not possible, you could: i) ignore the ldap error (same situation like now, at least for the user) ii) print the raw openldap error message iii) expect this error and print an own error message And you could describe, that it is not always possible, to remove the objectClass in the documentation.
Again requested in a UCS technical training (Ticket #2014092221000314) See attachment #4552 [details] for a script to force-fully remove objectClasses from LDAP entries. Removing objectClasses and their attributes is also relevant for later disabling options, for example the Samba Account information on a user account.
A possible workaround for removing the univentionFreeAttributes objectclass is described in a wiki article http://wiki.univention.de/index.php?title=Erstellen_eines_erweiterten_Attributs_mit_Hook.
It appears that this issue is not only related to the objectClass univentionFreeAttributes. I see the same for example with univentionXMPPAccount (defined by PLUCS). Maybe I don't understand the full meaning of this issue but at the moment I am attempted to say 'deleteObjectClass' does not work at all. If this is true I would expect at least expect a meaningful remark in the developer documentation.
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.
*** This bug has been marked as a duplicate of bug 41207 ***