[Date Prev][Date Next]
Re: v2.2.24 structural object class modification not allowed
- To: Curt Blank <email@example.com>
- Subject: Re: v2.2.24 structural object class modification not allowed
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Tue, 03 May 2005 12:59:50 -0700
- Cc: Aleksandar Milivojevic <firstname.lastname@example.org>, openldap-software@OpenLDAP.org
- In-reply-to: <4277CBCA.email@example.com>
- References: <4256CBE6.firstname.lastname@example.org> <4256FC6D.email@example.com> <firstname.lastname@example.org> <42576A54.email@example.com> <426176AB.firstname.lastname@example.org> <email@example.com> <4266A504.firstname.lastname@example.org> <4266B983.email@example.com> <4269F64A.firstname.lastname@example.org> <426A4F4D.email@example.com> <426D01C9.firstname.lastname@example.org> <426D0E8B.email@example.com> <426D178C.firstname.lastname@example.org> <426D1B56.email@example.com> <426D2386.firstname.lastname@example.org> <426DF07E.email@example.com> <firstname.lastname@example.org> <email@example.com> <4277C853.firstname.lastname@example.org> <4277CBCA.email@example.com>
At 12:06 PM 5/3/2005, Curt Blank wrote:
>Is everyone failing to remember that in OpenLDAP 2.0.27 this was *NOT* enforced? But that was ok? Now it's not?
As I believe has been previously noted in this thread,
slapd(8) failure to enforce this aspect of the model
was corrected in some subsequent release.
>Or did the X.500 spec change and that is now why OpenLDAP 2.2.24 enforces it?
The LDAP/X.500 specifications have not changed. The
server was changed to conform to the specification.
>Aleksandar Milivojevic wrote:
>Althogh it would be violation of the standard, it might be usefull feature in slapd to have run time option to allow addition/removals of structural object classes. Default, of course should be to be standard conformant and not allow such changes. The option would allow LDAP administrator to restructure his objects (if/when needed) without the need to dump/reload all entries in database.
Feel free to submit an ITS to request a feature enhancement
(there might already be one, I forget). IIRC, I believe addition
of such a feature was discussed on the openldap-devel mailing
list. The suggested mechanism was to allow change of the
change of structural object class (as well as certain other
NO-USER-MODIFICATION attributes) of an object via ManageDsaIT
(subject to "manage" access rights) or other extension mechanism.
This is intended to allow directory administrators, not directory
applications, to munge data held in the DSA.
Developers interested in this feature are encouraged to review
openldap-devel archives here and contribute as necessary to
provide an appropriate mechanism. I note that safely
providing this feature is not simply a matter of disabling a
check, as safety requires the server to otherwise ensure
directory consistency and correct behavior.