Bug 428232 - DN Rename with case change only fails
DN Rename with case change only fails
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Database - General (Show other bugs)
1.1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS112
  Show dependency treegraph
 
Reported: 2008-01-10 00:04 EST by Andrew Bartlett
Modified: 2015-01-04 18:29 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:01:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cvs diffs (3.74 KB, patch)
2008-07-29 10:59 EDT, Noriko Hosoi
no flags Details | Diff
modrdn test program (6.34 KB, text/plain)
2008-07-29 11:02 EDT, Noriko Hosoi
no flags Details
cvs diff ldapserver/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c (2.03 KB, patch)
2008-07-29 15:39 EDT, Noriko Hosoi
no flags Details | Diff
test program modrdn.c (7.00 KB, text/plain)
2008-07-29 15:44 EDT, Noriko Hosoi
no flags Details
cvs diff ldap/servers/slapd/back-ldbm/ldbm_modrdn.c (1.95 KB, patch)
2008-07-29 16:19 EDT, Noriko Hosoi
no flags Details | Diff
cvs commit ldbm_modrdn.c (641 bytes, text/plain)
2008-07-29 16:39 EDT, Noriko Hosoi
no flags Details

  None (edit)
Description Andrew Bartlett 2008-01-10 00:04:20 EST
Description of problem:


Version-Release number of selected component (if applicable):
current CVS

How reproducible:
Every time

Steps to Reproduce:
1. Attempt to rename cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into
cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com

Tested using Samba4 LDAP backend onto Fedora DS.  Test was ldap.js against Samba4
  
Actual results:
Could not rename cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into
cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com: LDAP error 68
LDAP_ENTRY_ALREADY_EXISTS -  <LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS -  <> <>> <>


Expected results:
Success

Additional info:
Rename with same case (ie identical) also fails.  Samba4 would work best if this
was handled in the same case, allowing a rename to the same value, as well as
any equivalent value. 

http://www.OpenLDAP.org/its/index.cgi?findid=5319
Comment 3 Noriko Hosoi 2008-07-29 10:59:00 EDT
Created attachment 312887 [details]
cvs diffs 

Files:
 slapi-plugin.h
 dn.c
 back-ldbm/ldbm_modrdn.c

Description: added additional checks if the original DN and the to-be-updated
DN are different in terms of the cases.  If the cases do not match, instead of
returning LDAP_ALREADY_EXISTS, continue the modrdn process.
Comment 4 Noriko Hosoi 2008-07-29 11:02:06 EDT
Created attachment 312890 [details]
modrdn test program

How to verify: 
1. Replace the modrdn.c in the mozilla ldap client's examples and compile it.
2. Prepare a suffix "dc=example,dc=com" on the test server.
3. run the program
$ ./modrdn <port> <directory_manager_password>
Added entry "cn=Jacques Smith, dc=example,dc=com".
Calling modrdn: "cn=Jacques Smith, dc=example,dc=com" => "cn=Jacques SMITH"
The modrdn operation was successful.  Entry
"cn=Jacques Smith, dc=example,dc=com" has been changed to
"cn=Jacques SMITH, dc=example,dc=com".
Comment 5 Nathan Kinder 2008-07-29 11:49:26 EDT
The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN
where the case matches to go through as well.  I guess the only reason we'd want
to return an error 68 is if the new DN is a different entry that already exists.
Comment 6 Noriko Hosoi 2008-07-29 12:11:53 EDT
(In reply to comment #5)
> The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN
> where the case matches to go through as well.

I wonder which is better "go through" or "return SUCCESS"?

> I guess the only reason we'd want
> to return an error 68 is if the new DN is a different entry that already exists.

That's true!  Let me reconsider it some more...

Comment 7 Nathan Kinder 2008-07-29 12:44:05 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN
> > where the case matches to go through as well.
> 
> I wonder which is better "go through" or "return SUCCESS"?

Letting the operation go through would ensure that the modifiedTime gets updated
properly, which a client may expect.
Comment 8 Noriko Hosoi 2008-07-29 15:39:34 EDT
Created attachment 312925 [details]
cvs diff ldapserver/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c

Thanks to Nathan for his suggestions, which were very useful.

The new proposal is much simpler.  If an entry which share the dn was found,
regardless of the case difference, it continues the modrdn process.  Note that
by checking the original dn and new dn are identical after normalizing them, we
could avoid the case that an entry having the original dn does not exist but
the one with the new dn already does.
Comment 9 Noriko Hosoi 2008-07-29 15:44:47 EDT
Created attachment 312926 [details]
test program modrdn.c

As suggested previously, replace modrdn.c with the attachment in
mozilla/directory/c-sdk/ldap/examples/, compile it.

# first, there is no "cn=Jacques Smith, dc=example,dc=com".  This program adds
the entry and rename it to "cn=Jacques SMITH, dc=example,dc=com":
$ ./modrdn <port> <directory_manager_password>
Added entry "cn=Jacques Smith, dc=example,dc=com".
Calling modrdn: "cn=Jacques Smith, dc=example,dc=com" => "cn=Jacques SMITH"
The modrdn operation was successful.  Entry
"cn=Jacques Smith, dc=example,dc=com" has been changed to
"cn=Jacques SMITH, dc=example,dc=com".

# Now "cn=Jacques SMITH, dc=example,dc=com" exists, the test program renames it
to itself, which does not fail.
$ ./modrdn <port> <directory_manager_password>
Entry "cn=Jacques SMITH, dc=example,dc=com is already in the directory.
Calling modrdn: "cn=Jacques SMITH, dc=example,dc=com" => "cn=Jacques SMITH"
The modrdn operation was successful.  Entry
"cn=Jacques SMITH, dc=example,dc=com" has been changed to
"cn=Jacques SMITH, dc=example,dc=com".
Comment 10 Noriko Hosoi 2008-07-29 16:19:53 EDT
Created attachment 312931 [details]
cvs diff ldap/servers/slapd/back-ldbm/ldbm_modrdn.c

Thanks, Nathan, for finding out the obsolete comment.  I removed it.
Comment 11 Noriko Hosoi 2008-07-29 16:39:27 EDT
Created attachment 312932 [details]
cvs commit ldbm_modrdn.c

Reviewed by Nathan (Thank you!!!)

Checked in ldbm_modrdn.c into CVS HEAD.

Note: The test program is attached to verify the fix.
Comment 12 Jenny Galipeau 2009-03-12 11:23:28 EDT
fix verified DS 8.1 RHEL 5

[root@jennyv2 jenny]# ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=bos,dc=redhat,dc=com" "(uid=mmouse)" dn
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=bos,dc=redhat,dc=com> with scope subtree
# filter: (uid=mmouse)
# requesting: dn 
#

# mmouse, People, bos.redhat.com
dn: uid=mmouse,ou=People, dc=bos, dc=redhat, dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[root@jennyv2 jenny]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -a -f modrdn.ldif 
modifying rdn of entry "uid=mmouse, ou=people, dc=bos, dc=redhat, dc=com"
rename completed

[root@jennyv2 jenny]# ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=bos,dc=redhat,dc=com" "(uid=mmouse)" dn
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=bos,dc=redhat,dc=com> with scope subtree
# filter: (uid=mmouse)
# requesting: dn 
#

# MMOUSE, People, bos.redhat.com
dn: uid=MMOUSE,ou=People, dc=bos, dc=redhat, dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
Comment 13 Chandrasekar Kannan 2009-04-29 19:01:33 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

Note You need to log in before you can comment on or make changes to this bug.