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)
Tracking
(Not tracked)
ASSIGNED
5.14
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
Assignee | ||
Comment 5•20 years ago
|
||
Here is a revised fix that also handles long comment lines.
Attachment #148296 -
Attachment is obsolete: true
Assignee | ||
Comment 6•20 years ago
|
||
Here is the entire read_one_record() function. Please give it a try (works for me).
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → 5.14
Comment 7•19 years ago
|
||
This proposed fix looks good. Has there been any other comment? What do we need to do to resolve this issue?
Assignee | ||
Comment 8•19 years ago
|
||
No other feedback from the original bug reporter. Rich, can you mark the proposed fix as reviewed?
Assignee | ||
Updated•18 years ago
|
Attachment #149208 -
Flags: review?(richm)
Comment 9•18 years ago
|
||
Mark - I'm not able to edit the attachment? I can't change the review? to review+
Assignee | ||
Updated•18 years ago
|
Attachment #149208 -
Flags: review?(richm)
Assignee | ||
Updated•18 years ago
|
Attachment #149208 -
Flags: review?(richm)
Assignee | ||
Comment 10•18 years ago
|
||
(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.
Updated•12 years ago
|
Attachment #149208 -
Flags: review?(richm) → review+
Comment 11•12 years ago
|
||
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.
Description
•