Description of problem: Endi came up with good test cases: This entry (a nested DN with one separator) is successfully added: $ ldapmodify -D 'cn=directory manager' -w <pw> -a << EOF dn: cn="a=b,c=d",ou=People,dc=example,dc=com objectClass: person objectClass: top cn: a=b,c=d sn: test1 EOF $ ldapsearch -b "dc=example,dc=com" "(cn=*)" dn dn: cn="a=b,c=d",ou=People,dc=example,dc=com But if there are more separators (2 commas in this example), it fails. $ ldapmodify -D 'cn=directory manager' -w <pw> -a << EOF dn: cn="a=b,c=d,e=f",ou=People,dc=example,dc=com objectClass: person objectClass: top cn: a=b,c=d,e=f sn: test2 EOF ldap_add: Invalid DN syntax ldap_add: additional info: DN value invalid per syntax The first case converts the DN cn="a=b,c=d",ou=People,dc=example,dc=com into cn=a=b\,c=d,ou=People,dc=example,dc=com. (This is not complete. '=' between 'a' and 'b' as well as 'c' and 'd' should be, too.) If there are more separators, it does not convert. I agree we have to convert the old style to new one consistently and completely.
The biggest challenge is the string length. The DN normalizer does in place normalizing. It does not expect the result is longer than the original. If we convert this dn: cn="a=b,c=d,e=f",ou=People,dc=example,dc=com to dn: cn=a\=b\,c\=d\,e\=f,ou=People,dc=example,dc=com the result is obviously longer than the original.
Created attachment 408196 [details] git patch file (master)
Created attachment 409036 [details] git patch file (master) Thanks to nkinder for his reviews and comments. Following his findings, these bugs were fixed. 1) If nsslapd-dn-validate-strict is set, check the incoming DNs and reject them if they are not valid. Once approved, the DNs are normalized. 2) Function in the acl plugin acllas__client_match_URL was calling slapi_dn_normalize_ext against URL (not DN), which was not a correct usage of the API. Now, the strict DN part is passed to the API. 3) Fixed typos in the acl plugin.
Created attachment 409231 [details] git patch file (master) Thanks to Nathan for finding out another bug: A file ldap/servers/slapd/config.c has no change. Removed the file from the previous patch 409036: git patch file (master).
Reviewed by Nathan. (Thank you sooooooo much!) Pushed to master. $ git push Counting objects: 215, done. Delta compression using 4 threads. Compressing objects: 100% (107/107), done. Writing objects: 100% (108/108), 39.13 KiB, done. Total 108 (delta 100), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 4754291..78c5066 master -> master
How to verify: grep ",cn=mapping tree" in the configuration file: $ egrep ",cn=mapping tree" /etc/dirsrv/slapd-ID/dse.ldif dn: cn=dc\3DbugA\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=dc\3DbugB\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config If the value of the leaf RDN is escaped as described in http://www.ietf.org/rfc/rfc4514.txt, then this bug is verified.
*** Bug 570962 has been marked as a duplicate of this bug. ***
verified RHEL 4 version: redhat-ds-base-8.2.0-2010051204.el4dsrv # egrep ",cn=mapping tree" /etc/dirsrv/slapd-jgalipea-rhel4/dse.ldif dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=o\3Dnetscaperoot,cn=mapping tree,cn=config