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

Logged in as guest

Viewing Software Bugs/6916
Full headers

From: michael@stroeder.com
Subject: slapo-unique returns operations error when assertion control is used
Compose comment
Download message
State:
0 replies:
9 followups: 1 2 3 4 5 6 7 8 9

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 26 Apr 2011 17:18:41 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: slapo-unique returns operations error when assertion control is used
Full_Name: Michael Str..der
Version: 2.4.25
OS: openSUSE Linux
URL: 
Submission from: (NULL) (195.145.144.134)


If an assertion control is sent along with a modify request slapo-unique returns
operation error with diagnostic message "unique_search failed" instead of
returning constraint violation.

Followup 1

Download message
Date: Tue, 26 Apr 2011 20:24:22 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
Further observations show that...

1. processing add requests seems to behave like expected.

2. it depends on the assertion filter sent in the control value:

$ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f
uidnumber_clash.ldif -e 'assert=(cn=*)'
modifying entry "uid=ttester,dc=stroeder,dc=de"
ldap_modify: Operations error (1)
	additional info: unique_search failed

$ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f
uidnumber_clash.ldif -e 'assert=(objectClass=*)'
modifying entry "uid=ttester,dc=stroeder,dc=de"
ldap_modify: Constraint violation (19)
	additional info: some attributes not unique




Followup 2

Download message
Date: Thu, 28 Apr 2011 18:50:45 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
Note that with assertion control always
Operations error: "unique_search failed"
is returned even if the attribute values are unique.

I'd really like to get this solved. web2ldap makes use of the assertion
control to ensure that an entry has not been changed since being edited by the
user. Otherwise I have to implement another vendor-specific hack switching off
this feature when OpenLDAP is used as server. :-(

Ciao, Michael.

michael@stroeder.com wrote:
> Further observations show that...
> 
> 1. processing add requests seems to behave like expected.
> 
> 2. it depends on the assertion filter sent in the control value:
> 
> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f
> uidnumber_clash.ldif -e 'assert=(cn=*)'
> modifying entry "uid=ttester,dc=stroeder,dc=de"
> ldap_modify: Operations error (1)
> 	additional info: unique_search failed
> 
> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f
> uidnumber_clash.ldif -e 'assert=(objectClass=*)'
> modifying entry "uid=ttester,dc=stroeder,dc=de"
> ldap_modify: Constraint violation (19)
> 	additional info: some attributes not unique



Followup 3

Download message
Date: Thu, 28 Apr 2011 15:21:43 -0700
From: Howard Chu <hyc@symas.com>
To: michael@stroeder.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
michael@stroeder.com wrote:
> Note that with assertion control always
> Operations error: "unique_search failed"
> is returned even if the attribute values are unique.
>
> I'd really like to get this solved. web2ldap makes use of the assertion
> control to ensure that an entry has not been changed since being edited by
the
> user. Otherwise I have to implement another vendor-specific hack switching
off
> this feature when OpenLDAP is used as server. :-(

First step toward a solution would be providing slapd -d output for the 
problem. Probably a sample config would help too.

> Ciao, Michael.
>
> michael@stroeder.com wrote:
>> Further observations show that...
>>
>> 1. processing add requests seems to behave like expected.
>>
>> 2. it depends on the assertion filter sent in the control value:
>>
>> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de"
-W -f
>> uidnumber_clash.ldif -e 'assert=(cn=*)'
>> modifying entry "uid=ttester,dc=stroeder,dc=de"
>> ldap_modify: Operations error (1)
>> 	additional info: unique_search failed
>>
>> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de"
-W -f
>> uidnumber_clash.ldif -e 'assert=(objectClass=*)'
>> modifying entry "uid=ttester,dc=stroeder,dc=de"
>> ldap_modify: Constraint violation (19)
>> 	additional info: some attributes not unique
>
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 4

Download message
Date: Fri, 29 Apr 2011 11:45:28 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
Howard Chu wrote:
> michael@stroeder.com wrote:
>> Note that with assertion control always
>> Operations error: "unique_search failed"
>> is returned even if the attribute values are unique.
>>
>> I'd really like to get this solved. web2ldap makes use of the assertion
>> control to ensure that an entry has not been changed since being
>> edited by the
>> user. Otherwise I have to implement another vendor-specific hack
>> switching off
>> this feature when OpenLDAP is used as server. :-(
> 
> First step toward a solution would be providing slapd -d output for the
> problem. Probably a sample config would help too.

(Sigh! Did anybody actually read through my report?)

Take any slapd.conf with database hdb and add these lines (no other overlays
configured):

overlay unique
unique_attributes uid uidNumber employeeNumber

Or any other LDAP-URL-based unique constraint...

Then apply a LDIF change record (example below) which contains any of the
attributes defined as unique (no matter whether unique constraint is violated
or not).

------------------------------- snip -------------------------------
dn: cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local
changetype: modify
replace: employeeNumber
employeeNumber: 456
-

------------------------------- snip -------------------------------

Try these commands (bind-DN is the rootdn here):

Without assertion control it works:
$ ldapmodify -H ldap://localhost:2071 -D
"uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif
modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local"

Assertion control just contains objectClass filter:
$ ldapmodify -H ldap://localhost:2071 -D
"uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e
'assert=(objectClass=*)'
modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local"

This fails:
$ ldapmodify -H ldap://localhost:2071 -D
"uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e
'assert=(cn=*)'modifying entry "cn=Anna
Blume,ou=Users,ou=schulung,dc=stroeder,dc=local"
ldap_modify: Operations error (1)
	additional info: unique_search failed


Output of slapd -d config,stats,stats2,acl,args,trace,sync:

------------------------------- snip -------------------------------
[..]
conn=1000 op=1 modifications:
	replace: employeeNumber
		one value, length 3
conn=1000 op=1 MOD dn="cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local"
conn=1000 op=1 MOD attr=employeeNumber
bdb_dn2entry("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local")
=> hdb_dn2id("ou=users,ou=schulung,dc=stroeder,dc=local")
<= hdb_dn2id: got id=0x6
=> hdb_dn2id("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local")
<= hdb_dn2id: got id=0xd
entry_decode: ""
<= entry_decode()
==> unique_modify <cn=Anna
Blume,ou=Users,ou=schulung,dc=stroeder,dc=local>
==> unique_search (|(employeeNumber=456))
put_filter: "(|(employeeNumber=456))"
put_filter: OR
put_filter_list "(employeeNumber=456)"
put_filter: "(employeeNumber=456)"
put_filter: simple
put_simple_filter: "employeeNumber=456"
ber_scanf fmt ({mm}) ber:
=> hdb_search
bdb_dn2entry("ou=schulung,dc=stroeder,dc=local")
=> access_allowed: search access to "ou=schulung,dc=stroeder,dc=local"
"entry"
requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
=> access_allowed: search access to "ou=schulung,dc=stroeder,dc=local" "cn"
requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
send_ldap_result: conn=1000 op=1 p=3
send_ldap_result: err=122 matched="" text=""
send_ldap_result: conn=1000 op=1 p=3
send_ldap_result: err=1 matched="" text="unique_search failed"
send_ldap_response: msgid=2 tag=103 err=1
ber_flush2: 34 bytes to sd 16
conn=1000 op=1 RESULT tag=103 err=1 text=unique_search failed
connection_get(16)
connection_get(16): got connid=1000
connection_read(16): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
op tag 0x42, time 1304069972
ber_get_next
ber_get_next on fd 16 failed errno=0 (Success)
conn=1000 op=2 do_unbind
conn=1000 op=2 UNBIND
connection_close: conn=1000 sd=16
conn=1000 fd=16 closed
------------------------------- snip -------------------------------



Followup 5

Download message
Date: Sun, 05 Jun 2011 16:27:21 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
Sad enough I had to turn off using the assertion control in upcoming web2ldap 
release as yet another vendor-specific workaround - this time for OpenLDAP...

It works with OpenDS and OpenDJ and web2ldap uses it with these servers.



Followup 6

Download message
Date: Wed, 8 Jun 2011 00:24:19 +0200 (CEST)
Subject: Re: (ITS#6916) slapo-unique returns operations error when 
     assertion control is used
From: masarati@aero.polimi.it
To: michael@stroeder.com
Cc: openldap-its@openldap.org
The problem seems to be that unique_modify() calls unique_search() passing
it an Operation that contains the assertion, which fails within the
search.  The failure is propagated back to the modification.  The
assertion control should not apply to internal operations performed by the
unique overlay.  The solution to me is not straightforward, apart from
explicitly removing the assert control when calling unique_search().  I
understand this solution is by no means general; similar problems may
surface in other overlays and with other controls.

p.



Followup 7

Download message
To: openldap-its@OpenLDAP.org
Cc: michael@stroeder.com
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion control
 is used
From: "Johannes Kanefendt" <Johannes.Kanefendt@krzn.de>
Date: Tue, 12 Jan 2016 17:00:33 +0100
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 0057F226C1257F38_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

A workaround is to extend the assertion filter to match all other entries=20
except the one to be modified:

(|(cn=3D*)(!(entryDN=3Dcn=3DAnna=20
Blume,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)))
--
Mit freundlichem Gru=DF
Im Auftrag

Johannes Kanefendt

Kommunales Rechenzentrum Niederrhein
Der Verbandsvorsteher
Abteilung 2.3.2 - Schulen Online
Friedrich-Heinrich-Allee 130
47475 Kamp-Lintfort -Germany-

Telefon: +49 (0)2842 90 70 125
Web: www.krzn.de
Email: Johannes.Kanefendt@krzn.de
--=_alternative 0057F226C1257F38_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<font size=3D2 face=3D"sans-serif">A workaround is to extend the assertion
filter to match all other entries except the one to be modified:</font>
<br>
<br><font size=3D2
face=3D"sans-serif">(|(cn=3D*)(!(entryDN=3Dcn=3DAnna Blu=
me,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)))</font>
<br><font size=3D2 face=3D"sans-serif">--</font>
<br><font size=3D2 face=3D"sans-serif">Mit freundlichem
Gru=DF</font>
<br><font size=3D2 face=3D"sans-serif">Im Auftrag</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Johannes
Kanefendt</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Kommunales Rechenzentrum
Niederrhein=
</font>
<br><font size=3D2 face=3D"sans-serif">Der
Verbandsvorsteher</font>
<br><font size=3D2 face=3D"sans-serif">Abteilung 2.3.2 - Schulen
Online</fo=
nt>
<br><font size=3D2 face=3D"sans-serif">Friedrich-Heinrich-Allee
130</font>
<br><font size=3D2 face=3D"sans-serif">47475 Kamp-Lintfort
-Germany-</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Telefon: +49 (0)2842 90 70
125</font>
<br><font size=3D2 face=3D"sans-serif">Web: </font><a
href=3Dwww.krzn.de><f=
ont size=3D2 color=3Dblue
face=3D"sans-serif">www.krzn.de</font></a><font s=
ize=3D2 face=3D"sans-serif"><br>
Email: Johannes.Kanefendt@krzn.de</font>
--=_alternative 0057F226C1257F38_=--



Followup 8

Download message
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion
 control is used
To: Johannes.Kanefendt@krzn.de, openldap-its@OpenLDAP.org
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
Date: Tue, 12 Jan 2016 20:13:15 +0100
Johannes.Kanefendt@krzn.de wrote:
> A workaround is to extend the assertion filter to match all other entries
> except the one to be modified:
> 
> (|(cn=*)(!(entryDN=cn=Anna\20Blume,ou=Users,ou=schulung,dc=stroeder,dc=local)))

The whole purpose of using the Assertion Control is that it should match the
modified entry. When I construct a filter deliberately not matching the entry I
can simply omit the Assertion Control completely.

Maybe I didn't get your idea though.

The use-case: My web2ldap sends Assertion Control along with a modify request
with a filter constructed from all attributes considered to be not modified by
another user:

(&(entryCSN=20160112183104\2e449732Z\23000000\23000\23000000)(creatorsName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(entryUUID=1c66859e\2d3441\2d1034\2d93db\2d751297a711ee)(modifiersName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(createTimestamp=20150119160811Z)(entryDN=ou=test\2cou=Testing\2cdc=stroeder\2cdc=de)(modifyTimestamp=20160112183104Z))

This is done to really ensure that the entry was *not* changed after being read
into the input form the user edits.

Ciao, Michael.



Followup 9

Download message
To: =?windows-1252?B?TWljaGFlbCBTdHL2ZGVy?= <michael@stroeder.com>,
	openldap-its@OpenLDAP.org
Subject: Re: (ITS#6916) slapo-unique returns operations error when assertion control
 is used
From: "Johannes Kanefendt" <Johannes.Kanefendt@krzn.de>
Date: Wed, 13 Jan 2016 09:02:31 +0100
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 002C2E33C1257F39_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Michael Str=F6der <michael@stroeder.com> schrieb am 12.01.2016 20:13:15:

> The whole purpose of using the Assertion Control is that it should match =

the
> modified entry. When I construct a filter deliberately not matching=20
> the entry I
> can simply omit the Assertion Control completely.

The logical outcome of the assertion doesn't change as the actual=20
assertion filter is or-ed with a rule that will never match the targeted=20
entry. However, when (wrongly) passed to unique=5Fsearch, it will prevent a=
=20
failure as all other entries than the target match.

>=20
> Maybe I didn't get your idea though.
>=20
> The use-case: My web2ldap sends Assertion Control along with a modify=20
request
> with a filter constructed from all attributes considered to be not=20
modified by
> another user:
>=20
> (&(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000)
> (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder
> \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\2d3=
441
> \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3
> \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder
> \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest
> \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121831=
04Z))
>=20

Try to enclose the assertion by=20
(|(...)(!(entryDN=3Dou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde))) or=20
(|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee)))

--=_alternative 002C2E33C1257F39_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<tt><font size=3D2>Michael Str=F6der
&lt;michael@stroeder.com&gt; schrieb
am 12.01.2016 20:13:15:<br>
<br>
&gt; The whole purpose of using the Assertion Control is that it should
match the<br>
&gt; modified entry. When I construct a filter deliberately not matching
<br>
&gt; the entry I<br>
&gt; can simply omit the Assertion Control
completely.</font></tt>
<br>
<br><tt><font size=3D2>The logical outcome of the assertion
doesn't change
as the actual assertion filter is or-ed with a rule that will never match
the targeted entry. However, when (wrongly) passed to unique=5Fsearch, it
will prevent a failure as all other entries than the target
match.</font></=
tt>
<br><tt><font size=3D2><br>
&gt; <br>
&gt; Maybe I didn't get your idea though.<br>
&gt; <br>
&gt; The use-case: My web2ldap sends Assertion Control along with a modify
request<br>
&gt; with a filter constructed from all attributes considered to be not
modified by<br>
&gt; another user:<br>
&gt; <br>
&gt; (&amp;(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000)<br>
&gt; (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder<=
br>
&gt; \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\=
2d3441<br>
&gt; \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3<b=
r>
&gt; \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder<=
br>
&gt; \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest<br>
&gt; \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121=
83104Z))<br>
&gt; <br>
</font></tt>
<br><tt><font size=3D2>Try to enclose the assertion by
(|(...)(!(entryDN=3D=
ou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde)))
or (|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee)))<br>
</font></tt>
--=_alternative 002C2E33C1257F39_=--


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