OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/6077
Full headers

From: andres@anarazel.de
Subject: Spurious uniqueness errors with filters in unique overlays
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Sat, 25 Apr 2009 01:01:51 +0000
From: andres@anarazel.de
To: openldap-its@OpenLDAP.org
Subject: Spurious uniqueness errors with filters in unique overlays
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 > \

Followup 1

Download message
Date: Sun, 26 Apr 2009 02:21:38 +0200
From: Andres Freund <andres@anarazel.de>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique
 overlays
This is a multi-part message in MIME format.
--------------080405020304060402030808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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



--------------080405020304060402030808
Content-Type: text/x-diff;
 name="slapd-unique-overlay-spurious-failure-fix-add.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="slapd-unique-overlay-spurious-failure-fix-add.patch"

--- openldap-2.4.16.saved/servers/slapd/overlays/unique.c	2009-04-23
23:51:37.925387747 +0200
+++ openldap-2.4.16/servers/slapd/overlays/unique.c	2009-04-26
01:58:54.566927667 +0200
@@ -1071,6 +1071,24 @@
 			     && !dnIsSuffix( &op->o_req_ndn, &uri->ndn ))
 				continue;
 
+			if (uri->filter.bv_val && uri->filter.bv_len){
+				Filter *f = str2filter_x(op,
+							 uri->filter.bv_val);
+				if(f == NULL) {
+					op->o_bd->bd_info = (BackendInfo *) on->on_info;
+					send_ldap_error(op, rs, LDAP_OTHER,
+							"unique_search invalid filter");
+					return(rs->sr_err);
+				}
+
+				if(test_filter(NULL, op->ora_e, f) == LDAP_COMPARE_FALSE){
+					Debug(LDAP_DEBUG_TRACE, "==> unique_add_skip<%s>\n",
+					      op->o_req_dn.bv_val, 0, 0);
+					continue;
+				}
+				filter_free_x(op, f, 1);
+			}
+
 			if(!(a = op->ora_e->e_attrs)) {
 				op->o_bd->bd_info = (BackendInfo *) on->on_info;
 				send_ldap_error(op, rs, LDAP_INVALID_SYNTAX,

--------------080405020304060402030808--



Followup 2

Download message
Date: Tue, 05 May 2009 12:14:47 +0200
From: Pierangelo Masarati <masarati@aero.polimi.it>
To: andres@anarazel.de
CC: openldap-its@openldap.org
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique
 overlays
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.



Followup 3

Download message
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique
 overlays
From: Simon Bin <sbin@informatik.uni-leipzig.de>
To: openldap-its@OpenLDAP.org
Cc: andres@anarazel.de
Date: Sun, 12 Apr 2015 23:18:36 +0200
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
    -






Followup 4

Download message
Date: Sun, 12 Apr 2015 15:14:36 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: sbin@informatik.uni-leipzig.de, openldap-its@OpenLDAP.org
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique
 overlays
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



Followup 5

Download message
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique
 overlays
From: Yann Soubeyrand <yann-externe.soubeyrand@edf.fr>
To: openldap-its@OpenLDAP.org
Cc: andres@anarazel.de
Date: Tue, 10 Jan 2017 16:38:39 +0100
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



Followup 6

Download message
From: wferi@niif.hu (Ferenc =?utf-8?Q?W=C3=A1gner?=)
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
Date: Mon, 19 Jun 2017 13:53:58 +0200
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


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org