Open Bug 233163 Opened 21 years ago Updated 12 years ago

ldapmodify fails if any line of the LDIF has 12286 characters.

Categories

(Directory :: LDAP C SDK, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: s_jayaram_s, Assigned: mcs)

Details

(Whiteboard: [needs un-bitrotted patch])

Attachments

(3 files, 2 obsolete files)

User-Agent:       
Build Identifier: 5.08

ldapmodify.exe fails to read the LDIF file entry if any line of the LDIF file 
has 12286 characters. Once the line with 12286 characters is read, ldapmodify 
considers it as the end of the entry and treats the next line as the start of 
new entry.
Because of this, the add\modify operations fail since the entry is read 
partially.

Reproducible: Always
Steps to Reproduce:
1.Use the attached LDIF file for testing.

2. Run the command "ldapmodify -h <server>-p <port> -
D <admin DN> -w <password> -c -v -f <the LDIF file>

From the verbose output ( ldapmodify is called with -v option) you will see 
that the last attribute read for the entry is 'sn'. The remaining attributes, 
are not read. Also, since ldapmodify is run with -c option, it considers the 
remaining lines of the ldif file as next entry and prints an error 
message "ldapmodify: skipping change record: no dn: line".
For this LDIF file,once all the attributes are read, the entry may not get 
added to the directory because of the length of the sn's value. However, the 
intention here is to make sure that ldapmodify.exe reads all the attributes of 
the entry.
3. Now, in the LDIF file,  change the value of sn (currently, the length of the 
line "sn: .." is 12286 chars); either add some characters or remove some 
characters so that the length of the entire line is not 12286.
4. Run the same command as given in step 2.
Now from the output of ldapmodify.exe, you will see that it reads all the 
attributes of the entry.
Actual Results:  
See the section "steps to reproduce".


Expected Results:  
Even when the length of the line is 12286, ldapmodify.exe should have read all  
attributes of the entry. 


Please note that the actual problem was faced with the value of the 
attribute "javaSerializedData". it is for a common example that I gave addition 
of a user in the LDIF file. What I observed is that, if a line is of length 
12286, ldapmodify.exe reads that line and considers it as the last attribute of 
the entry. The next line is read and treats it as the start of a new entry. 
When the line "dn: ..." is made of length 12286, the ldapmodify.exe did not 
read any attribute and gave an error message that "ldapmodify: no attributes to 
change or add".
Use this LDIF file for reproducing the problem. See teh sections "Steps to
reproduce" and "Additional Information".
(In reply to comment #0)
> User-Agent:       
> Build Identifier: 5.08
> ldapmodify.exe fails to read the LDIF file entry if any line of the LDIF file 
> has 12286 characters. Once the line with 12286 characters is read, ldapmodify 
> considers it as the end of the entry and treats the next line as the start of 
> new entry.
> Because of this, the add\modify operations fail since the entry is read 
> partially.
> Reproducible: Always
> Steps to Reproduce:
> 1.Use the attached LDIF file for testing.
> 2. Run the command "ldapmodify -h <server>-p <port> -
> D <admin DN> -w <password> -c -v -f <the LDIF file>
> From the verbose output ( ldapmodify is called with -v option) you will see 
> that the last attribute read for the entry is 'sn'. The remaining attributes, 
> are not read. Also, since ldapmodify is run with -c option, it considers the 
> remaining lines of the ldif file as next entry and prints an error 
> message "ldapmodify: skipping change record: no dn: line".
> For this LDIF file,once all the attributes are read, the entry may not get 
> added to the directory because of the length of the sn's value. However, the 
> intention here is to make sure that ldapmodify.exe reads all the attributes 
of 
> the entry.
> 3. Now, in the LDIF file,  change the value of sn (currently, the length of 
the 
> line "sn: .." is 12286 chars); either add some characters or remove some 
> characters so that the length of the entire line is not 12286.
> 4. Run the same command as given in step 2.
> Now from the output of ldapmodify.exe, you will see that it reads all the 
> attributes of the entry.
> Actual Results:  
> See the section "steps to reproduce".
> Expected Results:  
> Even when the length of the line is 12286, ldapmodify.exe should have read 
all  
> attributes of the entry. 
> Please note that the actual problem was faced with the value of the 
> attribute "javaSerializedData". it is for a common example that I gave 
addition 
> of a user in the LDIF file. What I observed is that, if a line is of length 
> 12286, ldapmodify.exe reads that line and considers it as the last attribute 
of 
> the entry. The next line is read and treats it as the start of a new entry. 
> When the line "dn: ..." is made of length 12286, the ldapmodify.exe did not 
> read any attribute and gave an error message that "ldapmodify: no attributes 
to 
> change or add".


I could verify that perl-ldap successfully processes this LDIF file.The problem 
is not observed when perl-ldap is used to import the LDIF file contents to 
directory.

The attachment fix-233163.txt has the modified function read_one_record which
has teh fix for this defect.
Attachment #148294 - Attachment description: The modified function 'read_one_record' which ahs the fix for this defect. → The modified function 'read_one_record' which has the fix for this defect.
This is the fix for this defect. The function read_one_record of ldapmodify.c
is modifed.
Attachment #148294 - Attachment is obsolete: true
Attached file revised fix
Here is a revised fix that also handles long comment lines.
Attachment #148296 - Attachment is obsolete: true
Here is the entire read_one_record() function.	Please give it a try (works for
me).
Status: NEW → ASSIGNED
Target Milestone: --- → 5.14
This proposed fix looks good.  Has there been any other comment?  What do we
need to do to resolve this issue?
No other feedback from the original bug reporter.  Rich, can you mark the
proposed fix as reviewed?
Attachment #149208 - Flags: review?(richm)
Mark - I'm not able to edit the attachment?  I can't change the review? to review+
Attachment #149208 - Flags: review?(richm)
Attachment #149208 - Flags: review?(richm)
(In reply to comment #9)
> Mark - I'm not able to edit the attachment?  I can't change the review? to
> review+

Strange.  Try again.  I removed the request for review and then added it back.
Attachment #149208 - Flags: review?(richm) → review+
Unfortunately this patch is bitrotted, would someone be able to update it?
Whiteboard: [needs un-bitrotted patch]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: