Bug 474621

Summary: Adding a user with nsuniqueid in the RDN creates an illegal entry
Product: [Retired] 389 Reporter: Nathan Kinder <nkinder>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: high    
Version: 1.1.1CC: benl, jgalipea, nhosoi, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:08:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
CVS Diffs none

Description Nathan Kinder 2008-12-04 17:20:50 UTC
If you add a new entry with a user-specified nsuniqueid, and use that attribute in the RDN, you end up having an illegal entry.  The nsuniqueid value gets automatically generated by the server, which replaces the user specified value.  The problem is that the DN still contains the user specified value in the RDN, which doesn't exist in the entry.

Add operation:

  dn: nsuniqueid=abcd, dc=example, dc=com
  changetype: add
  nsuniqueid: abcd
  objectclass: extensibleObject

Result:

  dn: nsuniqueid=abcd, dc=example, dc=com
  nsuniqueid: 0802df01-1dd211b2-8f26f2f9-3b160000

Comment 1 Nathan Kinder 2008-12-23 21:51:51 UTC
Created attachment 327773 [details]
CVS Diffs

These diffs check if the common created attributes are used as the RDN for both ADD and MODRDN operations.  We disallow using nsuniqueid, creatorsName, modifiersName, modifiedTimestamp, and createTimestamp in the RDN for an external ADD operation.  For a MODRDN, we disallow the same attributes in the new RDN with the exception of nsuniqueid.  We want to allow nsuniqueid in the RDN from internal operations for replication conflict entries.

The following messages will be returned to a client for operations violating the above:

ADD:

  adding new entry "nsuniqueid=abcd, dc=example, dc=com"
  ldap_add: Invalid DN syntax (34)
          additional info: illegal attribute in RDN

MODRDN:

  modifying rdn of entry "cn=foo,dc=example,dc=com"
  ldap_rename: Invalid DN syntax (34)
          additional info: invalid attribute in RDN

Comment 2 Nathan Kinder 2009-01-05 16:57:43 UTC
Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in ldap/servers/slapd/add.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/add.c,v  <--  add.c
new revision: 1.18; previous revision: 1.17
done
Checking in ldap/servers/slapd/modrdn.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/modrdn.c,v  <--  modrdn.c
new revision: 1.13; previous revision: 1.12
done

Comment 3 Jenny Severance 2009-03-17 14:53:05 UTC
fix verified RHEL 5 DS 8.1

[root@jennyv2 jenny]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -a -f 474621.ldif 
adding new entry "nsuniqueid=abcd, ou=people, dc=example, dc=com"
ldapmodify: Invalid DN syntax (34)
	additional info: illegal attribute in RDN


[root@jennyv2 jenny]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -a -f 474621.ldif 
modifying rdn of entry "uid=jenny, ou=people, dc=example, dc=com"
rename completed
ldapmodify: Invalid DN syntax (34)
	additional info: invalid RDN
(slight difference in error message on modrdn though)

Comment 4 Chandrasekar Kannan 2009-04-29 23:08:28 UTC
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