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

(ITS#7859) ldif processing issue with long lines



Full_Name: Mark Warren
Version: 2.4.35
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (72.35.133.119)


A customer of ours has identified an issue with slapadd and lines right at the
maximum length(4096 characters). Howard has taken a look and reports the
following:

I took a quick look at the slapadd issue; libldap/ldif.c is using an input
buffer of size [LDIF_MAXLINE] which is 4096 characters. It uses fgets() to read
the input.

The problem is that fgets() always stores a terminating NUL character, which
means the buffer can only accept an input of up to 4095 characters. The input
line in question is "only" 4095 characters long, but in reality it also has a
terminating newline, making it 4096. The end result, fgets() reads the data but
leaves the newline in the input buffer since there's no room for it in the user
buffer. Then the next call to fgets() returns just this newline all by itself,
which signals to ldif_read_record that it's come to the end of the entry, and so
it treats the next input line as a new entry even though it's supposed to be a
continuation of the previous line.

The simple fix here is to bump up the input buffer size by 1, to accommodate the
terminating newline. Actually the buffer needs to be upped by 2, to allow for
CR/LF line terminators.

 -- End Howard Quote --

Also, another issue has been reported where the length of LDIF lines is greater
by two than a specified 'ldif-wrap' definition when using slapcat.

Regards,
Mark Warren