Deletion of RDN and objectClass attribute

• Key: DIRSERVER-316
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Alex Karasulu
• Reporter: Stefan Zoerner

Description

It is possible to remove the RDN and the objectClass attribute from an entry via a modify operation. Removing the objectClass attribute leads to an entry which can't be deleted.

Attached you find a testcase which demonstrates the deletion of the objectClass on a person entry.
After this operation, it is still possible to lookup the entry with its DN, although it has no attributes and deletion attempts cause an error:
LDAP: error code 54 - failed to delete entry cn=Charly Brown,dc=apache,dc=org

Comments

[Stefan Zoerner]

Here is the test case. Output is

Deletion of attribute objectClass should fail.
cn=Charly Brown,dc=apache,dc=org
No attributes
javax.naming.NamingException: [LDAP: error code 54 - failed to delete entry cn=Charly Brown,dc=apache,dc=org:
org.apache.ldap.server.interceptor.InterceptorException: Unexpected exception. [Root exception is java.lang.NullPointerException]
at org.apache.ldap.server.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1202)
at org.apache.ldap.server.interceptor.InterceptorChain.access$500(InterceptorChain.java:49)
at org.apache.ldap.server.interceptor.InterceptorChain$2.delete(InterceptorChain.java:932)
...

I think this is all a result of not having proper schema checking in place. If the server checked to make sure a modify operation left a valid structural objectClass in place after all mods are applied then we would not have this problem. Likewise we should not allow the deletion of the RDN attributes without an RDN change. Overall schema checking is a mess we really need a central strategy behind it. For now I will add schema checks to make sure these consistency issues do not arrise.

[Alex Karasulu]

From Section 4.6 of RFC 2251:

+--------------------------------------------------------------------------------------------------------
 | The Modify Operation cannot be used to remove from an entry any of
 | its distinguished values, those values which form the entry's
 | relative distinguished name. An attempt to do so will result in the
 | server returning the error notAllowedOnRDN. The Modify DN Operation
 | described in section 4.9 is used to rename an entry.
+--------------------------------------------------------------------------------------------------------

[Alex Karasulu]

Started working on fixes for these problems and we can squeeze this into 0.9.2.

[Stefan Zoerner]

I refined my test cases according to Alex cite from RFC 2251. After this I found out that some servers provide other return codes, at least if the the removal is tried on a part of the RDN which is a required attribute as well (e.g. cn for person).

Sun JS DS 5.2: 65 - Object Class Violation
OpenLDAP 2.1: 64 - Naming Violation
IBM Tivoli 6.0: 67 - Not Allowed On RDN (at last)
MS ADAM: 67 - Not Allowed On RDN (inventive message text here: "CANT_ON_RDN")

I will therefor accept all three values in my test cases in order to keep the bar green for each solution. The 67 seems to be the better choice than 64, although it may depend on the fact that I used a required attribute as a RDN. The Sun server may check schema violations first, therfore its message is reasonable as well. Anyway, I will also add a test with a non required attribute as RDN.

[Alex Karasulu]

Committed resolving changes in revision 239501 here:

http://svn.apache.org/viewcvs.cgi?rev=239501&view=rev

[Stefan Zoerner]

I have rebuilded my Apache DS and verified, that neither the objectClass defect situation (as described in the test case) nor the RDN error case (as included in test cases of my little testsuite) appear (due to the Schema Service, which now prevents me from deleting those attributes). Error codes were fine, from my retest point of view, the bug is fixed as well. Thanks, Alex!

[Stefan Zoerner]

Retest was successful.