Issue 7859 - ldif processing issue with long lines
Summary: ldif processing issue with long lines
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.35
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-26 17:30 UTC by mwarren@symas.com
Modified: 2020-03-22 03:01 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description mwarren@symas.com 2014-05-26 17:30:39 UTC
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
Comment 1 Howard Chu 2014-05-27 01:50:34 UTC
mwarren@symas.com wrote:
> 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.

This appears to be the result of an intentional backward-compatiblility 
kludge. While the spec may have defaulted to 76 chars, the UMich code has 
always output 78 columns by default, so there's an offset built in to the LDIF 
output functions. This offset wasn't taken into account when the variable 
output width support was written.

Probably we should just remove the kludge and define our default output width 
to 78 instead of pretending it's still 76.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 2 Quanah Gibson-Mount 2014-05-29 11:06:23 UTC
changed notes
changed state Open to Release
moved from Incoming to Software Bugs
Comment 3 OpenLDAP project 2014-10-23 07:31:27 UTC
fixed in master
fixed in RE24
fixed in RE25
Comment 4 Quanah Gibson-Mount 2014-10-23 07:31:27 UTC
changed notes
changed state Release to Closed