Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \
Fixing this for unique_add seams easy enough (see preliminary attached patch) - fixing it for modrdn/modify seems to be another difficulty level as in order to properly apply the filter I think the full modifications have to be applied... If wanted I can produce a patch for this as well, but I would like to know if that is appreciated and if my plan for fixing looks sensible: - Pull the "modification simulation" code out of constraint.c (line 959:1040 and some more in 2.4.16) into constraints.c - Add a overlay-int.h - Make constraint.c and unique.c use that As I dont really know the openldap codebase my analysis could be completely wrong - I would appreciate some feedback. Andres
andres@anarazel.de wrote: > This is a multi-part message in MIME format. > --------------080405020304060402030808 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit Your analysis looks correct. In fact, the uniqueness check for add seems to assume that the current entry will implicitly match the uniqueness filter, which may not be the case if an additional filter is provided within the URI. > Fixing this for unique_add seams easy enough (see preliminary attached > patch) - fixing it for modrdn/modify seems to be another difficulty > level as in order to properly apply the filter I think the full > modifications have to be applied... > > If wanted I can produce a patch for this as well, but I would like to > know if that is appreciated and if my plan for fixing looks sensible: > - Pull the "modification simulation" code out of constraint.c (line > 959:1040 and some more in 2.4.16) into constraints.c > - Add a overlay-int.h > - Make constraint.c and unique.c use that > > As I dont really know the openldap codebase my analysis could be > completely wrong - I would appreciate some feedback. Yes, the code provided in the constraint overlay is exactly intended to simulate the modification in order to be able to assess the consistency of the resulting entry with the constraint. What you suggest sounds reasonable; a patch would definitely be welcome. The code extracted from constraint.c should probably be placed in slapd, and always built since other portions of slapd might need it in the future. Please note that overlays can be selectively built, or even built as modules, so creating cross-dependences is not a good idea IMHO. p.
changed notes changed state Open to Feedback moved from Incoming to Software Bugs
changed notes changed state Feedback to Test
changed notes
changed notes changed state Test to Partial
Should I be having this issue on OpenLDAP 2.4.40? I have the filter ldap:///?gidNumber?sub?(objectClass=posixGroup) and cannot use gidNumber in posixAccount's. This was working in 2.4.31 if I recall correctly. #!RESULT ERROR #!ERROR [LDAP: error code 19 - some attributes not unique] dn: cn=User Name,ou=People,dc=... changetype: modify replace: gidNumber gidNumber: 10000 -
I would suggest testing current RE24, somes fixes to slapo-unique went in last week. --Quanah --On Sunday, April 12, 2015 10:19 PM +0000 sbin@informatik.uni-leipzig.de wrote: > Should I be having this issue on OpenLDAP 2.4.40? I have the filter > > ldap:///?gidNumber?sub?(objectClass=posixGroup) > > and cannot use gidNumber in posixAccount's. This was working in 2.4.31 > if I recall correctly. > > #!RESULT ERROR > #!ERROR [LDAP: error code 19 - some attributes not unique] > dn: cn=User Name,ou=People,dc=... > changetype: modify > replace: gidNumber > gidNumber: 10000 > - > > > > > > -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi, It seems to be the same bug as bug #6825. If so, this bug is still present in 2.4.44. Regards Yann Soubeyrand
I guess e338789d is supposed to fix this, and it's present in 2.4.40, but still I'm affected on that version: olcUniqueURI: ldap:///o=niifi,o=niif,c=hu?gidNumber?sub?objectClass=posixGroup rejects setting the gidNumber of a posixAccount to that of an existing posixGroup. The usual workaround of using more specific base DNs doesn't work well for me, because there are multiple branches containing groups. Specifying multiple URIs on the above light might work (man slapd-unique doesn't tell precisely), but requires extra maintenance. -- Feri
modify fixed in HEAD; modrdn needs work modify fixed in RE24; modrdn needs work See also ITS#6825