Univention Bugzilla – Full Text Bug Listing |
Summary: | deleteObjectClass=1 wird beim Modifizieren nicht respektiert | ||
---|---|---|---|
Product: | UCS | Reporter: | Daniel Hofmann <hofmann> |
Component: | UDM - Extended Attributes | Assignee: | UMC maintainers <umc-maintainers> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | best, botner, C.Herrmann, da, ebersbach, gohmann, gulden, hahn, klaeser, steuwer, t.springmann |
Version: | UCS 2.4 | ||
Target Milestone: | UCS 3.x | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: | https://forge.univention.org/bugzilla/show_bug.cgi?id=41207 | ||
What kind of report is it?: | --- | 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: |
Description
Daniel Hofmann
2009-10-07 14:01:07 CEST
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 *** |