[Date Prev][Date Next] [Chronological] [Thread] [Top]

LDIF lexing error in LDIF with CRLF terminators



Current LDIF handling in 2.0.x and 2.1.x in ldapmodify does not work
correctly with LDIF files containing CRLF line terminators.

RFC-2849, line 209 defines the line separator as CR LF or LF.

Running ldapadd/ldapmodify on LDIF with CRLF causes it to exit with
"success" after processing the first entry.

i.e., given an ldif file like


dn: ou=a, o=foo
objectclass: top
objectclass: organizationalUnit
ou: a

dn: ou=b, o=foo
objectclass: top
objectclass: organizationalUnit
ou: b

dn: ou=c, o=foo
objectclass: top
objectclass: organizationalUnit
ou: c


stored with CRLF line terminators,

ldapmodify -n -a -f test.ldif

replies with

!adding new entry "ou=a, o=foo"


And stops right there.  Commenting out the first entry causes it to
process only the second.

I expect this problem only shows up on systems with LF line
termination trying to process LDIF files with CRLF.  (which is why no
one else has squawked)

The problem appears to be an off-by-one error in ldapmodify.c, line 1245.  Trivial patch is attached:

diff -wNru openldap-2.1.3-orig/clients/tools/ldapmodify.c openldap-2.1.3/clients/tools/ldapmodify.c
--- openldap-2.1.3-orig/clients/tools/ldapmodify.c      2002-06-06 08:54:12.000000000 -0700
+++ openldap-2.1.3/clients/tools/ldapmodify.c   2002-08-02 15:45:04.000000000 -0700
@@ -1245,7 +1245,7 @@
     while ( fgets( line, sizeof(line), fp ) != NULL ) {
        int len = strlen( line );
 
-               if( len < 2 || ( len == 3 && *line == '\r' )) {
+               if( len < 2 || ( len == 2 && *line == '\r' )) {
                        if( buf == NULL ) {
                                continue;
                        } else {



This should apply cleanly to both 2.0.25 and 2.1.3.  I have not looked
at the 1.2 series...

Matthew Backes
lucca@csun.edu