Bug 1099654 - Normalization from old DN format to New DN format doesnt handel condition properly when there is space in a suffix after the seperator operator.
Summary: Normalization from old DN format to New DN format doesnt handel condition pro...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-20 20:26 UTC by Noriko Hosoi
Modified: 2015-03-05 09:34 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-03-05 09:34:39 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

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


Note You need to log in before you can comment on or make changes to this bug.