Full_Name: Paul R. Turgyan Version: 1.2.9 OS: Solaris 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.211.168.36) slapd allows an entry's rdn to be replaced. If a ldapmodify user issues a replace operation for the rdn attribute, slapd will blow away all the corresponding attributes, and remove the rdn from the associated indexes. This makes the entry hard to find. We have modified servers/slapd/back-ldbm/modify.c to correct this problem. We have yet to put this change into production, but are planning to real soon.
moved from Incoming to Software Bugs
At 02:47 PM 3/13/00 GMT, pturgyan@umich.edu wrote: >Full_Name: Paul R. Turgyan >Version: 1.2.9 >OS: Solaris 5.6 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (141.211.168.36) > > >slapd allows an entry's rdn to be replaced. If a >ldapmodify user issues a replace operation for the rdn >attribute, slapd will blow away all the corresponding >attributes, and remove the rdn from the associated indexes. >This makes the entry hard to find. > >We have modified servers/slapd/back-ldbm/modify.c to correct this >problem. We have yet to put this change into production, but are >planning to real soon. Can you provide a patch for this?
Yep -- I ftp'd over paul_turgyan_000317.diff to you at about 14:25 est. > At 02:47 PM 3/13/00 GMT, pturgyan@umich.edu wrote: > >Full_Name: Paul R. Turgyan > >Version: 1.2.9 > >OS: Solaris 5.6 > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (141.211.168.36) > > > > > >slapd allows an entry's rdn to be replaced. If a > >ldapmodify user issues a replace operation for the rdn > >attribute, slapd will blow away all the corresponding > >attributes, and remove the rdn from the associated indexes. > >This makes the entry hard to find. > > > >We have modified servers/slapd/back-ldbm/modify.c to correct this > >problem. We have yet to put this change into production, but are > >planning to real soon. > > Can you provide a patch for this? >
At 02:25 PM 3/17/00 -0500, Paul R. Turgyan wrote: >I ftp'd over paul_turgyan_000317.diff to you at about 14:25 est. Your patch backout recent changes to modify.c. Also, please provide unified (-u) patches whenever possible. 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.
> 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 the RDN. On some servers, including the RDN in such a replace is an error. Hence, many clients explicitly don't include the RDN. Under the current OpenLDAP implementation, no explicitly including the RDN causes the database to be corrupted. For maximum compatibility, this patch is supposed to silently add the RDN when it is missing, thus making both client implementations correct. We originally added the code to oc_schema_check(), but backed it out in favor of this more correct patch. I'm not familiar with entry_schema_check(). :wes
At 12:01 AM 3/18/00 GMT, wesley.craig@umich.edu 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 >the RDN. 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. That is: dn: cn=foo, o=bar changetype: replace replace: cn cn: foo 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 LDAP servers. >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 work. >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 3.3.3.3.4.2 of the Basic LDAP Interoperability Test. <http://www.opengroup.org/directory/mats/blits23/blits23.htm>. I believe this BLITS test is consistent with LDAPv2 and LDAPv3 requirements. We don't currently pass this test [I would like to fix this]. >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. >entry_schema_check() 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. I recommend: 1) OpenLDAP be designed to adhere closely to the specifications and, as allowed by these specifications, to be liberal in accepting odditities. 2) Allow for certain checks to be disabled [naming, schema, etc]. 3) Allow for certain compatibility codes to be enabled [auto-RDN-add].
I looked at oc_schema_check(), and initially we had something in there to re-add the rdn if one of the clients like ud said to replace the rdn. We were re-adding the attribute to the attribute list, but the attribute/value would get deleted from the indexes. So we 'd have a good entry, but noone could find it. I'll look at this again, getting the latest version of modify.c I'll also look at the 2.0 stuff "schema_check_entry" > At 02:25 PM 3/17/00 -0500, Paul R. Turgyan wrote: > >I ftp'd over paul_turgyan_000317.diff to you at about 14:25 est. > > Your patch backout recent changes to modify.c. Also, > please provide unified (-u) patches whenever possible. > > 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. >
changed notes changed state Open to Closed
no action taken