[moved to devel for specification/implementation discussions] I note that in my current working draft specifying ManageDIT, direct modification of the structuralObjectClass attribute is disallowed. Instead, objectClass is updated as desired and structuralObjectClass is re-derived. This way, the client doesn't have to update both objectClass and structuralObjectClass to effect the change.
However, I think permission-wise, we might still require manage on structuralObjectClass so that permission to cause object metamorphism is separate from permission to override other objectClass restrictions that manageDIT might relax. I plan on submitting my working draft in the next day... Kurt At 12:54 AM 2/25/2006, Pierangelo Masarati wrote: >On Fri, 2006-02-24 at 17:55 +0100, Jehan PROCACCIA wrote: >> Pierangelo Masarati wrote: >> >> >On Thu, 2006-02-23 at 18:36 +0100, Pierangelo Masarati wrote: >> > >> > >> > >> >>I was about to reply something like that, as I remember that some >> >>functionality of manageDIT was present, but I found out that there's no >> >>structuralObjectClass change capability yet. I've already added the >> >>capability to change creatorsName, createTimestamp and entryUUID (which I >> >>needed to implement cross-database rename in a distributed system); in >> >>case I might work at structuralObjectClass (based on spare time >> >>availability, of course). If anyone is willing to contribute, please >> >>remember that manageDIT modifications require "manage" access privileges. >> >> >> >> >> > >> >I need to partially amend my first posting: you can already change the >> >structuralObjectClass using the manageDIT; what that control requires is >> >that the resulting entry complies with the schema. So, if your entry >> >initially looks like >> > >> >dn: sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr >> >objectClass: person >> >cn: Communication and Image >> >sn: CITI >> > >> >you can add the organizationalPerson objectClass provided you do >> >something like >> > >> >dn: sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr >> >changetype: modify >> >add: objectClass >> >objectClass: organizationalPerson >> >- >> >replace: structuralObjectClass >> >structuralObjectClass: organizationalPerson >> >- >> > >> >and, of course, you need to use the manageDIT control and have "manage" >> >access to structuralObjectClass. >> > >> >p. >> > >> I never "played" with manageDIT controls ... I don't know how to set >> "manage access to structuralObjectClass". I suposse it is an ACL to set >> in slapd.conf ? have you a example ? > >access to attrs=structuralObjectClass > by ... manage > by ... =m > >> In the client part, it's just a matter of adding option "-M" ? > >-e manageDIT > >> >> here's my latest, still, uncessfull test: >> $ ldapmodify -M -f /tmp/add-dept.ldif -h localhost -D >> cn=admin,dc=int-evry,dc=fr -W -x >> Enter LDAP Password: >> modifying entry "sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr" >> ldap_modify: Constraint violation (19) >> additional info: structuralObjectClass: no user modification allowed > >Use -e manageDIT; note that this works with HEAD; I'm pretty sure the >code is present in 2.3 as well, although the control is not advertised, >but some bits of it might be disabled. > >> >> $ cat /tmp/add-dept.ldif >> dn: sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr >> changetype: modify >> add: objectClass >> objectClass: organizationalPerson >> - >> replace: structuralObjectClass >> structuralObjectClass: organizationalPerson >> - >> >> Am I in the right direction ? > >Sort of; of course, if you use the rootdn identity you don't need any >access control. > >p. > > > > >Ing. Pierangelo Masarati >Responsabile Open Solution >OpenLDAP Core Team > >SysNet s.n.c. >Via Dossi, 8 - 27100 Pavia - ITALIA >http://www.sys-net.it >------------------------------------------ >Office: +39.02.23998309 >Mobile: +39.333.4963172 >Email: [EMAIL PROTECTED] >------------------------------------------
