|
[Problem Description] Renaming suffix returns the return code LDAP_UNWILLING_TO_PERFORM with the message "Renaming suffix is not allowe", which does not describe the problem correctly. $ ldapmodify -D 'cn=directory manager' -w pw dn: dc=example,dc=com changetype: modrdn newrdn: dc=new deleteoldrdn: -1 modifying RDN of entry dc=example,dc=com ldap_rename: DSA is unwilling to perform ldap_rename: additional info: Cannot move entries accross backends The right error code/message should be ldap_rename: DSA is unwilling to perform ldap_rename: additional info: Renaming suffix is not allowed [Fix Description] If the target dn of the modrdn operation is a suffix,
check if the new dn already exists or not. If it exists, it returns
LDAP_ALREADY_EXISTS. If the backend associated with the new dn does
not exist, it returns LDAP_NO_SUCH_OBJECT. Otherwise, it returns
LDAP_NAMING_VIOLATION.
If the target dn of the modrdn is attempted to move across backends,
it returns LDAP_AFFECTS_MULTIPLE_DSAS instead of LDAP_UNWILLING_TO_PERFORM.
Modrdn (op_shared_rename) was logging the parameter errors in the
clients request as SLAPI_LOG_FATAL. Reduced the level to SLAPI_LOG_ARGS.
Also, replaced ldap_explode_dn with slapi_dn_syntax_check to verify
the newsuperior.
By the replacement, 2 bugs in slapi_dn_syntax_check were found.
1) The key for the DN in the hashtable of the attribute syntax has
to be "distinguishedName". 2) Argument type for plg_syntax_validate
was not correct.
[Proposed Fix]
Created an attachment (id=387689) [details]
git patch file
|
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
