Bug 1099654

Summary:	Normalization from old DN format to New DN format doesnt handel condition properly when there is space in a suffix after the seperator operator.
Product:	Red Hat Enterprise Linux 7	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	nkinder, rmeggins, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:	Cause: DN normalizer (slapi_dn_normalize_ext) follows RFC 4514 and keeps a white space if the RDN attribute type is not based on the DN syntax. But Directory server's configuration entry sometimes uses "cn" to store a DN value (e.g., dn: cn="dc=A,dc=com",cn=mapping tree, cn=config), which expects the value of cn treated as DN although cn is not a DN syntax type. Consequence: Configuration DNs which are different from each other by white spaces around a separator are treated as 2 different DNs. Fix: To solve the problem, this patch introduces a configuration parameter "nsslapd-cn-uses-dn-syntax-in-dns" to "cn=config" which takes "on" or "off". If "on" is set, if the value of cn under "cn=config" is quoted, it's processed as DN. Result: Configuration entries which has DN in the CN value is always handled correctly.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:34:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Noriko Hosoi 2014-05-20 20:26:14 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47720

Hi,

For example there is a suffix say cn="dc=example,<space here>dc=com". As per new style DN syntax, it should be converted as below

     New DN after normalization: cn=dc\3Dexample\2Cdc\3Dcom
Here, the space should be removed after separator operator(','), but this not handled properly in our current implementation.

I have gone through the code and made the following change to address this scenario.

Function name:
int
slapi_dn_normalize_ext(char *src, size_t src_len, char **dest, size_t *dest_len)
 
case INVALUE:    /* in value; cn=ABC */


  } else if (ISSPACE(*s)) {
                /* remove extra spaces, e.g., "cn=ABC   DEF" -->      
                "cn=ABC DEF" */
                /*============New Code==========================*/
                /* Here we need to have a check to determine whether
                /* the previous character to the space is a */
                /* separator  operator and if yes, we need to all the*/
                /* space after the separator operator */
                /*======================================*/
                if (!SEPARATORSTR(s-2)){ /* New check for this isse */
                    *d++ = *s++;
                 }
                 while (ISSPACE(*s))
                      s++;

Comment 1 Noriko Hosoi 2014-05-22 22:54:36 UTC

Steps to verify:
stop the server
set "nsslapd-cn-uses-dn-syntax-in-dns: off" in cn=config
start the server.

ldapsearch ... -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns
nsslapd-cn-uses-dn-syntax-in-dns: off

Add the following 3 entries.  All should be successfully added.
==> test0.ldif <==
dn: cn="dc=abc,   dc=def,   dc=com",cn=config
objectClass: extensibleObject
objectClass: top

==> test1.ldif <==
dn: cn="dc=abc,dc=def,dc=com",cn=config
objectClass: extensibleObject
objectClass: top

==> test2.ldif <==
dn: cn="dc=abc   ,dc=def    ,dc=com",cn=config
objectClass: extensibleObject
objectClass: top
-------------------------------------------------------------------------
stop the server
set "nsslapd-cn-uses-dn-syntax-in-dns: on" in cn=config
start the server.

ldapsearch ... -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns
nsslapd-cn-uses-dn-syntax-in-dns: on

Add the following 3 entries.  Only the first one is successfully added and the rest is rejected with error "Already exists".
==> test0.ldif <==
dn: cn="dc=abc,   dc=def,   dc=com",cn=config
objectClass: extensibleObject
objectClass: top

==> test1.ldif <==
dn: cn="dc=abc,dc=def,dc=com",cn=config
objectClass: extensibleObject
objectClass: top

==> test2.ldif <==
dn: cn="dc=abc   ,dc=def    ,dc=com",cn=config
objectClass: extensibleObject
objectClass: top

Comment 3 Viktor Ashirov 2015-01-10 19:39:19 UTC

Tested on: 
$ rpm -qa | grep 389-ds
389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64
389-ds-base-1.3.3.1-11.el7.x86_64
389-ds-base-libs-1.3.3.1-11.el7.x86_64


[1] nsslapd-cn-uses-dn-syntax-in-dns is off
$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns
dn: cn=config
nsslapd-cn-uses-dn-syntax-in-dns: off


$ ldapmodify -D "cn=Directory Manager" -w Secret123 -c -a  << EOF
dn: cn="dc=abc,   dc=def,   dc=com",cn=config
objectClass: extensibleObject
objectClass: top

dn: cn="dc=abc,dc=def,dc=com",cn=config
objectClass: extensibleObject
objectClass: top

dn: cn="dc=abc   ,dc=def    ,dc=com",cn=config
objectClass: extensibleObject
objectClass: top
EOF
adding new entry "cn="dc=abc,   dc=def,   dc=com",cn=config"

adding new entry "cn="dc=abc,dc=def,dc=com",cn=config"

adding new entry "cn="dc=abc   ,dc=def    ,dc=com",cn=config"


[2] nsslapd-cn-uses-dn-syntax-in-dns is on
$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b "cn=config" -s base nsslapd-cn-uses-dn-syntax-in-dns
dn: cn=config
nsslapd-cn-uses-dn-syntax-in-dns: on


$ ldapmodify -D "cn=Directory Manager" -w Secret123 -c -a  << EOF
dn: cn="dc=abc,   dc=example,   dc=com",cn=config
objectClass: extensibleObject
objectClass: top

dn: cn="dc=abc,dc=example,dc=com",cn=config
objectClass: extensibleObject
objectClass: top

dn: cn="dc=abc   ,dc=example    ,dc=com",cn=config
objectClass: extensibleObject
objectClass: top
EOF
adding new entry "cn="dc=abc,   dc=example,   dc=com",cn=config"

adding new entry "cn="dc=abc,dc=example,dc=com",cn=config"
ldap_add: Already exists (68)

adding new entry "cn="dc=abc   ,dc=example    ,dc=com",cn=config"
ldap_add: Already exists (68)


Only the first one is successfully added and the rest is rejected with error "Already exists".
Marking as VERIFIED

Comment 5 errata-xmlrpc 2015-03-05 09:34:39 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html