Bug 15841 - deleteObjectClass=1 wird beim Modifizieren nicht respektiert
deleteObjectClass=1 wird beim Modifizieren nicht respektiert
Status: RESOLVED DUPLICATE of bug 41207
Product: UCS
Classification: Unclassified
Component: UDM - Extended Attributes
UCS 2.4
Other Linux
: P5 normal (vote)
: UCS 3.x
Assigned To: UMC maintainers
:
: 5579 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-07 14:01 CEST by Daniel Hofmann
Modified: 2018-04-13 13:29 CEST (History)
11 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Hofmann univentionstaff 2009-10-07 14:01:07 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"
Comment 1 Daniel Hofmann univentionstaff 2009-10-07 14:12:52 CEST
Testfälle 60_delete_object_class in den Paketen ucs-test-udm-customattributes bzw. ucs-test-udm-extendedattributes hinzugefügt.
Comment 2 Stefan Gohmann univentionstaff 2010-11-02 21:37:07 CET
Erneut aufgetreten: Ticket #2010102910000505
Comment 3 Felix Botner univentionstaff 2011-11-29 14:58:43 CET
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
Comment 4 Andreas Büsching univentionstaff 2011-12-12 15:31:21 CET
*** Bug 5579 has been marked as a duplicate of this bug. ***
Comment 5 Philipp Hahn univentionstaff 2013-11-11 08:32:48 CET
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.
Comment 6 Alexander Kläser univentionstaff 2013-11-11 09:27:41 CET
(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.
Comment 7 ch 2014-09-02 13:41:34 CEST
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.
Comment 8 Philipp Hahn univentionstaff 2014-10-01 11:04:56 CEST
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.
Comment 9 Jan Christoph Ebersbach univentionstaff 2014-12-01 12:21:44 CET
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.
Comment 10 Dirk Ahrnke 2015-12-07 15:45:39 CET
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.
Comment 11 Stefan Gohmann univentionstaff 2016-04-25 07:51:55 CEST
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.
Comment 12 Florian Best univentionstaff 2016-05-25 12:38:22 CEST

*** This bug has been marked as a duplicate of bug 41207 ***