[Date Prev][Date Next]
Re: Slapd blows away rdn (ITS#475)
At 12:01 AM 3/18/00 GMT, firstname.lastname@example.org wrote:
>> From: Kurt@OpenLDAP.org
>> To: openldap-its@OpenLDAP.org
>> Anyways, I think a better solution would be to modify
>> oc_schema_check() to do the check and to return a specific
>> result code/error text. And, optionally, s/oc_/entry_/.
>> Then we'd be able to catch missing rdn on add and modify.
>Actually, this is meant to catch the replace case. E.g. RDN is formed
>with cn, a replace of "cn" is made, which does not necessarily contain
If a modify operation is made (replace/delete) which would
results in the removal of the values used in the RDN, the server
should return a notAllowedOnRDN (0x43) error. However, a server
should not disallow a removal of other values of same attribute.
dn: cn=foo, o=bar
should not result in an notAllowedOnRDN error.
>On some servers, including the RDN in such a replace is an error.
I believe this to be incorrect behavior. What resultCode/message
text is returned by an operation similiar to above?
>Hence, many clients explicitly don't include the RDN.
Which should result in a notAllowedOnRDN error on most modern
>Under the current OpenLDAP implementation, no explicitly including the RDN
>causes the database to be corrupted.
Likely the result of the multiple value indexing bug in 1.2.9.
Does it occur with the latest OPENLDAP_REL_ENG_1_2?
Also, OpenLDAP does do RDN checks which might result in entries which
don't conform to X.500 information model... but they *should* otherwise
>For maximum compatibility, this patch is supposed to silently add
>the RDN when it is missing, thus making both client implementations correct.
And cause the server to fail test 126.96.36.199.4.2 of the Basic LDAP
I believe this BLITS test is consistent with LDAPv2 and LDAPv3
requirements. We don't currently pass this test [I would like to
>We originally added the code to oc_schema_check(), but backed it out in
>favor of this more correct patch.
I believe adding the check to oc_schema_check is more correct as
it will allow slapd to detect a missing RDN that would result from
a modify (and add) operation. Note, it's the entry that would
result that from the operation that should be checked, not the
specifics of the operation itself. This is because the set
of modifications presented by a modify request must be treated
as one operation, not a series of operations.
oc_schema_check() was renamed in openldap-devel to better reflect
what it does. It should be extended to directly return a resultCode
and a error message.
1) OpenLDAP be designed to adhere closely to the specifications
and, as allowed by these specifications, to be liberal in
2) Allow for certain checks to be disabled [naming, schema, etc].
3) Allow for certain compatibility codes to be enabled [auto-RDN-add].