- openldap-bugs - openldap.org

(ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by coudot＠linagora.com 20 Apr '12

20 Apr '12

Full_Name: Clément OUDOT Version: 2.4.30 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error: clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control # # search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule # numResponses: 1 I think the error should only be returned if the control is critical. Else, the search results should be returned, not sorted. A patch was proposed in ITS 6647, it was working when applied to 2.4.23 version: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 20 Apr '12

20 Apr '12

On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote: > On Thu, 19 Apr 2012 14:58:32 GMT, masarati(a)aero.polimi.it wrote: >>> I do have a patch+Perl script which wraps all operation(op, rs) >>> calls, but it doesn't know which ops are "internal". >> >> I don't think it's something that can be done automatically. Careful code >> review and testing would be required. >> >>> I want it for the SlapReply cleanup (ITS#6758). The only way to >>> make a hunt for dirty SlapReplies feasible. I suggested it when >>> I was doing the cleanup, but IIRC nobody replied - except there >>> were related complaints that my cleanup was too invasive. >>> >>> http://www.openldap.org/lists/openldap-devel/201101/msg00039.html >>> http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt >>> >>> Anyway, here's me trying agin again:-) >> >> Sort of recall it. Well, it looks pretty invasive, indeed. The two >> things should be kept separate. No preference about the order in which >> the two changes should be applied. I'm in no hurry to work at internal >> ops (mostly because I have scarce time for it and I'm worried about >> possible unexpected showstoppers). >> >> Maybe, if all calls for internal operations are wrapped by a macro, then >> ITS#6758 SlapReply cleanup could be performed just from within that >> macro; >> calls that are not judged internal would need to be explicitly wrapped, >> though. > > No, I meant the opposite: The macroization is done. It could mostly be > scripted and makes no semantic change unless #ifdef(SlapReply debug), > which is what the macros were for. Right. > Figuring out which ops to tag as internal does, as you say, require > review and testing. And one extra arg to the macros. How do you suggest to proceed? I believe using different macros, e.g. slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is clearer than having an additional 0/1 parameter. OTOH, adding further parameters in the future would be probably easier if we extend your macros. At this point, we need consensus on addressing ITS#6758 in the first place. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 19 Apr '12

19 Apr '12

On Thu, 19 Apr 2012 14:58:32 GMT, masarati(a)aero.polimi.it wrote: >> I do have a patch+Perl script which wraps all operation(op, rs) >> calls, but it doesn't know which ops are "internal". > > I don't think it's something that can be done automatically. Careful > code > review and testing would be required. > >> I want it for the SlapReply cleanup (ITS#6758). The only way to >> make a hunt for dirty SlapReplies feasible. I suggested it when >> I was doing the cleanup, but IIRC nobody replied - except there >> were related complaints that my cleanup was too invasive. >> >> >> http://www.openldap.org/lists/openldap-devel/201101/msg00039.html >> http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt >> >> Anyway, here's me trying agin again:-) > > Sort of recall it. Well, it looks pretty invasive, indeed. The two > things should be kept separate. No preference about the order in > which > the two changes should be applied. I'm in no hurry to work at > internal > ops (mostly because I have scarce time for it and I'm worried about > possible unexpected showstoppers). > > Maybe, if all calls for internal operations are wrapped by a macro, > then > ITS#6758 SlapReply cleanup could be performed just from within that > macro; > calls that are not judged internal would need to be explicitly > wrapped, > though. No, I meant the opposite: The macroization is done. It could mostly be scripted and makes no semantic change unless #ifdef(SlapReply debug), which is what the macros were for. Figuring out which ops to tag as internal does, as you say, require review and testing. And one extra arg to the macros. Hallvard

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 19 Apr '12

19 Apr '12

> On Thu, 19 Apr 2012 06:16:16 GMT, masarati(a)aero.polimi.it wrote: >> A definitive and simple solution, although invasive, would be to: >> >> - add a o_internal flag to the Operation structure >> >> - add a macro BE_INTERNAL(op, rs, op_type) like >> >> #define BE_INTERNAL(op, rs, op_type, rcp) \ >> { >> int save_o_internal = op->o_internal; >> op->o_internal = 1; >> *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); >> op->o_internal = save_o_internal; >> } > > I imagine connection.c:operation_fake_init() should set > op->o_internal and any callers which disagree should unset it Good point. >> fix all calls to internal operations (brrr....) > > I do have a patch+Perl script which wraps all operation(op, rs) > calls, but it doesn't know which ops are "internal". I don't think it's something that can be done automatically. Careful code review and testing would be required. > I want it for the SlapReply cleanup (ITS#6758). The only way to > make a hunt for dirty SlapReplies feasible. I suggested it when > I was doing the cleanup, but IIRC nobody replied - except there > were related complaints that my cleanup was too invasive. > > http://www.openldap.org/lists/openldap-devel/201101/msg00039.html > http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt > > Anyway, here's me trying agin again:-) Sort of recall it. Well, it looks pretty invasive, indeed. The two things should be kept separate. No preference about the order in which the two changes should be applied. I'm in no hurry to work at internal ops (mostly because I have scarce time for it and I'm worried about possible unexpected showstoppers). Maybe, if all calls for internal operations are wrapped by a macro, then ITS#6758 SlapReply cleanup could be performed just from within that macro; calls that are not judged internal would need to be explicitly wrapped, though. p.

1 0

(ITS#7252)
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

This is a multipart message in MIME format. --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT regarding the first answer of my mail in the mailinglist applying the patch does not change the behavior! Patch: diff --git a/servers/slapd/back-sql/search.c b/servers/slapd/back-sql/search.c index cadd036..92d3f82 100644 --- a/servers/slapd/back-sql/search.c +++ b/servers/slapd/back-sql/search.c @@ -325,7 +325,7 @@ backsql_init_search( rc = rs->sr_err = LDAP_REFERRAL; rs->sr_ref = referral_rewrite( erefs, &bsi->bsi_e->e_nname, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , scope ); ber_bvarray_free( erefs ); @@ -2336,7 +2336,7 @@ backsql_search( Operation *op, SlapReply *rs ) if ( refs ) { rs->sr_ref = referral_rewrite( refs, &e->e_name, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , op->ors_scope ); ber_bvarray_free( refs ); } --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DDE link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>regarding the first answer of my mail in the = mailinglist<o:p></o:p>applying the patch does not change the = behavior!<o:p></o:p><o:p> </o:p><o:p> </o:p>Patch:<o:p></o:p><o:p> </o:p>diff --git = a/servers/slapd/back-sql/search.c = b/servers/slapd/back-sql/search.c<o:p></o:p>index cadd036..92d3f82 = 100644<o:p></o:p>--- = a/servers/slapd/back-sql/search.c<o:p></o:p>+++ = b/servers/slapd/back-sql/search.c<o:p></o:p>@@ -325,7 +325,7 @@ = backsql_init_search(<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rc =3D rs->sr_err =3D = LDAP_REFERRAL;<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rs->sr_ref =3D referral_rewrite( = erefs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       = &bsi->bsi_e->e_nname,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       scope );<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   ber_bvarray_free( erefs );<o:p></o:p>        = <o:p></o:p>@@ -2336,7 +2336,7 @@ backsql_search( = Operation *op, SlapReply *rs )<o:p></o:p> =             &= nbsp;         if ( refs ) = {<o:p></o:p> =             &= nbsp;           &n= bsp;     rs->sr_ref =3D referral_rewrite( = refs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        &e->e_name,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp; &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp; NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        op->ors_scope = );<o:p></o:p> =             &= nbsp;           &n= bsp;     ber_bvarray_free( refs = );<o:p></o:p> =             &= nbsp;         }<o:p></o:p><o:p> </o:p></div></body></html>= --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg)--

1 0

(ITS#7252) Referral Problem with SQL Backend
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

Full_Name: Robert Eikermann Version: 2.4.23 OS: Ubuntu 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.226.168.114) Hi, regarding my mail to the mailinglist: http://www.openldap.org/lists/openldap-technical/201204/msg00053.html I'm using openldap with SQL-Backend (Postgres). The configured referral on this server behaves not the way it should. The bind dn of the referral is overwritten by the bind dn (of ldapsearch). Following are the configuration and the Log files of the LDAP Server with SQL Backend at Loglevel -1. In the Logfile you can see the starting of the server + the search ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de. I think at line 4114 one can see how the referral is used. Slapd.conf : http://pastebin.com/tvtdNaZ6 sql attribute mappings: http://image-upload.de/image/WcDeaB/fd191aa422.png sql entries: http://image-upload.de/image/qGiBOY/51496a9462.png sql object classes: http://image-upload.de/image/Rei0X3/4f6b2b43f5.png sql oc mapping: http://image-upload.de/image/TRscIQ/7141e04af6.png sql referral: http://image-upload.de/image/LGxZKQ/28773fadf7.png ldap Log: http://pastebin.com/N8NCyLzt To demonstrate the behavior: Search for the referral Object: user@user-desktop:~$ ldapsearch -M -xLLL -h localhost:389 "(objectClass=referral)" '*' ref dn: dc=tim,dc=sselab,dc=de objectClass: referral objectClass: extensibleObject dc: tim ref: ldap://localhost:390/dc=tim,dc=sselab,dc=de# which is exactly what I want! But searching all objects: user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de dn: dc=sselab,dc=de objectClass: dcObject dc: sselab # refldap://localhost:390/dc=sselab,dc=de??sub Results with the wrong dn in refldap! Search with the dc=tim DN : user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=tim,dc=sselab,dc=de Referral (10) Referral: ldap://localhost:390/dc=tim,dc=sselab,dc=de??sub If you need more Information please let me know. Best regards Robert Eikermann

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 19 Apr '12

19 Apr '12

On Thu, 19 Apr 2012 06:16:16 GMT, masarati(a)aero.polimi.it wrote: > A definitive and simple solution, although invasive, would be to: > > - add a o_internal flag to the Operation structure > > - add a macro BE_INTERNAL(op, rs, op_type) like > > #define BE_INTERNAL(op, rs, op_type, rcp) \ > { > int save_o_internal = op->o_internal; > op->o_internal = 1; > *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); > op->o_internal = save_o_internal; > } I imagine connection.c:operation_fake_init() should set op->o_internal and any callers which disagree should unset it > fix all calls to internal operations (brrr....) I do have a patch+Perl script which wraps all operation(op, rs) calls, but it doesn't know which ops are "internal". I want it for the SlapReply cleanup (ITS#6758). The only way to make a hunt for dirty SlapReplies feasible. I suggested it when I was doing the cleanup, but IIRC nobody replied - except there were related complaints that my cleanup was too invasive. http://www.openldap.org/lists/openldap-devel/201101/msg00039.html http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt Anyway, here's me trying agin again:-) -- Hallvard

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 19 Apr '12

19 Apr '12

>> Thanks. The explanation is always simple, after one finds it. The DN >> of >> accesslog entries is generated using the reqStart AVA. When logops all >> and internal operations take place, multiple entries are generated with >> the same reqStart AVA. So an internal search which is logged because of >> some overlay eats up the DN of the modrdn, and be_add() called by >> slapo-accesslog(5) fails because the entry already exists. >> >> Although logging internal entries could be of some use, I see two >> solutions: >> >> - modify the value of reqStart (e.g. instead of using o_tincr for the >> fractional part of the timestamp, we could use an incremental counter >> initialized with o_tincr and incremented at each logging within the same >> operation. The counter could be stored somewhere in the operation >> structure (e.g. in o_extra) >> >> - prevent logging of internal ops; again, this could be achieved by >> setting a dedicated o_internal_op field in the Operation structure. >> >> Since this modification could be intrusive, I'd like to gather some >> comments before proceeding with a fix. > > Hm, we've run into this similar problem before with syncprov and > introduced > op->o_dont_replicate. As a general rule, accesslog is meant to log user > operations, not internal operations. Currently accesslog checks > (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. > I > guess we need a more general flag instead. A definitive and simple solution, although invasive, would be to: - add a o_internal flag to the Operation structure - add a macro BE_INTERNAL(op, rs, op_type) like #define BE_INTERNAL(op, rs, op_type, rcp) \ { int save_o_internal = op->o_internal; op->o_internal = 1; *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); op->o_internal = save_o_internal; } fix all calls to internal operations (brrr....) p.

1 0

(ITS#7251) MDB shared mutexes ambiguous on Apple/Windows
by hyc＠OpenLDAP.org 19 Apr '12

19 Apr '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.151.244.127) Submitted by: hyc Currently since MacOSX and Windows don't support process-shared mutexes residing in shared memory, MDB uses global named semaphores instead on these platforms. The semaphore name is derived from a hash of the pathname of the lock file. This approach was quick and dirty and is prone to failure if relative paths and absolute paths are mixed, or if a file can be accessed thru multiple paths (e.g. symlinks, loopback mounts, whatever). Instead of the pathname, a unique file identifier of the lock file should be used. For MacOSX we can obtain (device,inode) using fstat(). For Windows we can obtain (dwVolumeSerialNumber,nFileIndexLow,nFileIndexHigh) using GetFileInformationByHandle().

1 0

Re: ITS#7239: testbed
by hyc＠symas.com 19 Apr '12

19 Apr '12

masarati(a)aero.polimi.it wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms020801020604080509050502 >> Content-Type: text/plain; charset=ISO-8859-15 >> Content-Transfer-Encoding: quoted-printable >> >> masarati(a)aero.polimi.it wrote: >>> =20 >>> The attachment is unreadable; can you ftp it somewhere? Thanks, p. >> >> http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 > > Thanks. The explanation is always simple, after one finds it. The DN of > accesslog entries is generated using the reqStart AVA. When logops all > and internal operations take place, multiple entries are generated with > the same reqStart AVA. So an internal search which is logged because of > some overlay eats up the DN of the modrdn, and be_add() called by > slapo-accesslog(5) fails because the entry already exists. > > Although logging internal entries could be of some use, I see two solutions: > > - modify the value of reqStart (e.g. instead of using o_tincr for the > fractional part of the timestamp, we could use an incremental counter > initialized with o_tincr and incremented at each logging within the same > operation. The counter could be stored somewhere in the operation > structure (e.g. in o_extra) > > - prevent logging of internal ops; again, this could be achieved by > setting a dedicated o_internal_op field in the Operation structure. > > Since this modification could be intrusive, I'd like to gather some > comments before proceeding with a fix. Hm, we've run into this similar problem before with syncprov and introduced op->o_dont_replicate. As a general rule, accesslog is meant to log user operations, not internal operations. Currently accesslog checks (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. I guess we need a more general flag instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

> This is a cryptographically signed message in MIME format. > > --------------ms020801020604080509050502 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >>=20 >> The attachment is unreadable; can you ftp it somewhere? Thanks, p. > > http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 Thanks. The explanation is always simple, after one finds it. The DN of accesslog entries is generated using the reqStart AVA. When logops all and internal operations take place, multiple entries are generated with the same reqStart AVA. So an internal search which is logged because of some overlay eats up the DN of the modrdn, and be_add() called by slapo-accesslog(5) fails because the entry already exists. Although logging internal entries could be of some use, I see two solutions: - modify the value of reqStart (e.g. instead of using o_tincr for the fractional part of the timestamp, we could use an incremental counter initialized with o_tincr and incremented at each logging within the same operation. The counter could be stored somewhere in the operation structure (e.g. in o_extra) - prevent logging of internal ops; again, this could be achieved by setting a dedicated o_internal_op field in the Operation structure. Since this modification could be intrusive, I'd like to gather some comments before proceeding with a fix. p.

1 0

Re: ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020801020604080509050502 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >=20 > The attachment is unreadable; can you ftp it somewhere? Thanks, p. http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 --------------ms020801020604080509050502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxODIwNTAyOFowIwYJKoZIhvcNAQkEMRYE FO5TfD14PMXVNCzh4rtO6MQEgfVNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAWC2ZU3Z19tk5FafFmH93ox5VIq85YoZoKvQEjiZC/aWis578hUnfkJXS/Dh+Ltt+dyj/ t3DzDSlJHBbvjyAoReVO54SwPKpJZE8SadEXNLK31Cs6J0QJFHt3gW9nW2wr/sXcNnLHqxxm fq8Ofn3ztGC5bxBa2BYTKGq/23Oa6zDK/5GfG7BTw4KZ4JlpGat0/12z9oqDgNkYCEEHFmVa bXNGpFnV5e0+ngjIqBvdRt80iuV9et3vXRBWrJWJMC0uA5NfKWldOh3Ov4WL/GKl2PtCWRo0 Q3twLoa88WPMWDdZzKeKRLvxQxMtYCh2ZIk74aNAATNXPznIDyMnlWPqOAAAAAAAAA== --------------ms020801020604080509050502--

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

The attachment is unreadable; can you ftp it somewhere? Thanks, p.

1 0

ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a multi-part message in MIME format. --------------000704030300080804030201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit See openldap-testbed-its7239.tar.bz2 attached. You have to adjust paths in the config of course. ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f initial.ldif ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f modrdn.ldif Now look at the accesslog DB: ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" => no results. Now repeat that with "logops writes" instead of "logops all": rm db/*/* ldapadd... ldapmodify... $ ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope oneLevel # filter: (objectClass=auditModRDN) # requesting: ALL # # 20120418194545.000001Z, accesslog dn: reqStart=20120418194545.000001Z,cn=accesslog objectClass: auditModRDN reqStart: 20120418194545.000001Z reqEnd: 20120418194545.000002Z reqType: modrdn reqSession: 1001 reqAuthzID: uid=diradm,ou=schulung,dc=stroeder,dc=local reqDN: uid=test1,ou=schulung,dc=stroeder,dc=local reqResult: 0 reqMod: entryCSN:= 20120418194545.412289Z#000000#000#000000 reqMod: modifiersName:= uid=diradm,ou=schulung,dc=stroeder,dc=local reqMod: modifyTimestamp:= 20120418194545Z reqNewRDN: uid=test2 reqDeleteOldRDN: TRUE reqEntryUUID: 86014e61-7c47-4062-931f-39526f738016 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------000704030300080804030201 Content-Type: application/x-bzip2; name="openldap-testbed-its7239.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7239.tar.bz2" QlpoOTFBWSZTWUmYCwUAHGV/pf7wIiB//////+///v////4AQEABQAAACGAYTc+5LsPvZ6D5 S0u9988PvuzvWcErt3vmfHtqpub6fXnZrqotFaNWzWqBSlaalKe2+3rXQclH00F7PXeEkhBG mIU9pMnpMTRT8ieptUep6ZTyjaTNQep6mnqPUwmmgeobU0yHqCSITEAJpKeanqbSpptG0j1G iDaTxTQep6hhAMaNAgMQBiJqZBU2p6g9qjRo9QGmajQBoaABoAAZAaAaaDCTUiECRmk9KP0R ogyNNDIekMmgGjQAA0AGmgAEVET1CmnjU0mhiab1TENMmTJkMgyDaIPU0NGIeoMQGjAkSCAE ARkI0yaT0A0KnkhsoaHqaBoNNGQaGgAPShWelmPPk8yZHbmS0CkHt1gnOGQDrIJCM+7nzfOc Z72Sqn4gqiDACCJRBhlQZGTF3hTvhTvZsGMJikIgTnLCIQGUJJIZUVEREUIJEJ3/vXuwnL7p h3znhR3iv2MqIbboLeIBa0NpJjEKAunYNEppc/8z2oXvOhXcOtedrYOHXT4cOK+BIpwcvGhh 3rpNlphr7KbU4qZBqPd5JTP4b5kzQsRFrYeTYoyPyO2pMXZeuz3bMfqwXrYiphmDAdn3jf+O qu/IsCyfb+1mfpLOPWlcNDaA2J95Jrz8+3sfZOWNO7R9/fXyupdZdO27I5jOHhB4NNpNtMsj 3eQM98bZDYslevmFrskMW6HaOzD3qoqlC/zVcT/aUU2KORwxAnm50pFOzZbZqCFbDKcVOyWC lHkKw+R2kr0ZbuEjc2mVeLq69FdhfdFiC08bNU1Azp2+uPze6MAxeP5Ll2vd7SO4JxeO6fCQ jeAwGqU3mugGJ6g6TI82RW0Z0ehKN+Dm9RmdFORarbZkLW0xmfbq9mHPbZl/xsI8ZhSzlsPo JMSEH0ZqDugLWjzoTQghG4wFUhiGcVicNgXpyDAhYPoSZgqkT4zA5QWBQ1EtyVOi79Orq4m8 26fG2+bvViPZTLw+GqXWeFK98VtI8mG38E38EC/H9aYxChiGNTQtqf64f2g11kkgmJ7zbgT4 ++vXWu17abfMoXxNUh4Q2gQhTxw0aURDyMaKROl4U4w4bT072Vhso7qWsOMXF7+pIMPsHQE2 r8TqlkfLIXuKn5zSCDE+nX4eesv9xhEz3Skw458ZIfd3Ekc4IwHyKBcEl+nvrv+dFLkcsydz DGkDrBP1WcfzmZSofJoL77NROzH25fZH13e8Wt/I0I45rlhL09SsK2TIL+cHvlx+JMxYYhjx lLHixxdze1zRXjdw0Ia5T2DYfWcTI9JYHxRXXrxE69qnPFsYWUNFZE02shprwKa1+bGyBtJ4 MWWubpGPnILszMj24321nWdN/a2zO5np27zmuibmxyTkOKuic8s7eC8SoHOb3wYZOHJb4OfL DGYWxt037dQqLa7hql0EBcZ4E/5zLurQ1Y4u9HdoZG6K7lePA8dbMe2BbrsG12cdoX2rYa9s 7zu6i2K2naGeGebxh5i7LRdunRDgrkRYUto+yeJSgykk3ulSGTy4XGXCPMo6+6tnnOOWGSwZ jGnfWRkdlxFweYw5C9LXKtvHbJeRsGfBnJbFtp3iJIEGbd3opT0RGKq2HBIGxRyl+zFLXtvV Z/5bdCW/ZIz5bB1dxotZoXnZ3XSMEwLdakUtJULO7NTVWcsSTnuZMmplpyYJI4iQJccNiiP0 nDuSST7zyjAX/EzxqK8tmedVfcEKqn1pD/UgsCLAgLAUIcsFfDFWIrACoCkmBG7Wybdrq42H Iptw6k2jiRJFemKBLGK5iy/fhg8M1zhMFoTG9HLFofMpI0ENdP6Wz6PBUt6BAB822kqtrN9W NzLrhTdRp8164pkzLVvMwsoOALx/JdV8cNs/gqIbufg8vXf1rv79IHwys9CJulGHpPhhzyT0 er2NM3iursXVdQtfwmC4VEVTnX2wpGFIzS0QrYZs7rVnvS4jTLppJX2pzSWj2uLm5yoS0pL0 efh4DzfjBeWMj6WJi1oVv0FVvwdx/iJjn2BFrygHR9EARWCDdLmkcT2EI3jOJJ9OaOylyRQQ A2zn9xO6xnsIRSWtBglmZyjbfsxz5i9ekNi+SQQoYJsfkAiIckIgKuEKovIDwSAkheN6Z5zy XhL2qQIMxNkkSAQxNo/G9Tw70sFmRyhGO/m3a05XdH67x++8Oh21wKRnoqZdP5Zauj8X4wYw fT00Pws13lqHUB+P3tEKb1qn9W5KdGbeAjelKQF96DQnYFUNNDWXXJWITNGsKU16eYNtLHjB ZGEhYoGV8ULrfPA5oEw4gd3s/oPdWwSSN6IE06OY9dgHaJTgkGFRSSQgJCbbQqeSSHX1YeX9 9/P1dU6StjJDFxVPETsTfDZObiu6RfrIKnC+CRa5j6+O8lhfZzt/vJx+LOOtf0Wu+WR7656J BACIAQ0kBoPHXaSBFG9s2PzmL+YeytHBHz2CHjF0gspGOe2fVKFUKYbQuuSCsFOFUggc8lEw Z6tNlNIaGTEscMyBOjvdCHNtUg2+evYSkCMOeCygfmOT5RxbQvSB8xNI/Jx3IRIxGwhshDrw pGfPMljZE/QOUm4sfrRi7Eb7nLCErW3kUCM8GYqhEmhWq21iQSjQmWwQiMEKiSvrRUpWoOeB VAi2QjZnN3ZUMEjAmILW6qAQ2oI2isrY7IsxusKY0mO/E+ZJIJnF1he0S+hSoIm2FIONiTuE eimQiJ1E5y0u0h5X4lAEUSCtsM0DUZjnqRvZFl4UCcqEFUFTGCQLgWQiU5pRhe2JuDdYTUIp XjywERi117pFg7vmqoVd9hYX44wxbQ6ZTIGNOaVTp2jU0ThBRa7i5+rovnwtjNfU+HRBy6eJ Kevi49xJmx5HQaRmiiKjzThO1oPlvc3vL+yje9UHX29FQLO5IOx2RJlJ26CV9LLPAe0vr+3s TXme5p5pjq/MAmETgGyFYT9V5OiZz3xnvKnsWN/tHqJiN0Y9GL0CZ+1oTu/cN95lQmMwxPjF UCUlfrOseHL8X9nWb0eWfUi+UhWVJE4xS0wSn9IqOL3lkQZRkJmXVJPicOdrTZ2SlLYkdohD RkAYJHI3wbfzGmgMBvy3hRgk8Qyz+w9wTPXtjaPM9YcDP9rquUGLKhyObtkAUvU9RcYMx4iN CxNnDoZ8pBL3b+4PmIvDiAeSgcC8+wxSVTQ9Zv2aoqbjsOwgcgYZmV07txlDerMwBWIiSXR8 zgDgMncLJtZdw0GdmYuEI1kSDgtvcH86biJQ2H5Mc/IMEce2HHd9MwTUJJyFcDWBG4WvwSQ/ m37zZdB4+DbaD4oSOi2o5k6ksic5ScXHSzaH1Hr31XmR3d2S9OhoWLGOuXboRMhajlhqSWQx HCONorkG5bNdmh1MqWRATzq2kd8sEN6MGaCNlza8VrWf0vNw7wS8DoR6QGsep94agtVajEMg hQDGhpkH2sOI+Blslm/HUa7ZncGvPmdKSGG9raBspqEEl3Ly0ZMjQXVpluYM6FB/FcnrAGEU K4tjNCyYANqgpAMdpCROyL4giYMRKI5ZQBUWFlWFpUnCsUFjuaDOl65tPzPqOXrO8+AxQQzs JGKF8Uc22ga+cZ0hQEMugQ7I+lEASBgAdfHpysThPJ+JZzSsi8zHQZwKYBmfeesR++uL/UbD 6H6EdKYwxLVdf9ZRoRB8Mgd4uA3Ky0WVRx7icSnClxkUiYpqIIJr33ej9B3A3CbpNO7JWBfk DQiKCCQVgiKDhM1UvQ84Y20ldJaay1PTzi4FAGhW2UCHOIkg2EdL4IVIzDQ6SiXl4HKyoSe7 OCWvqPYYBmwcENChkJFlp6RDusbrrDodIIbAcRB7gi9SOHbYYtmGOV2xUMIVzreFg8mRGDSW Ikl206i3N8/AcrDALQPjvCNcxMbbDcu486AIFkgCD1LOiYbG31bf7BdpO8QxGSETAjJIMTkT u7sCxL3et28QWMhgQytBaLUY4DUpSqEFpI9rDaTMWte19G0B0o0TSRFgZGfQ39DXaKwYJMoN iS5EGSqJZOhDQgaSBsMSQr+3fnO4MZkwR9G2gHMVqtngMFaGUtQDkKZQuUWLGqBlJqyIUdN7 ilSkqiz0iAckmRwaJJ9viIg8zPeMKnAQf16v+9+UlvNpIlJKGBsElkmwsVeFkvRje3YW9obX x8qhiicwwuN8GxhQMG+aiwwRzDnzlOYpQhhUsniGNpMlcZxCUD41FSX0rpkkDXkKPmPt+B63 wRUR9DsEh3ngI3Gj7Gd5wWaOLWjvtVd4wGFNWU3iQfYSFsGEbEwFj2DEeOBHlkVWDWsvzwHw Mqjb/UXRUmqmZjGlJgUN+2xoGuZi1C7Hp4hq6+ulYJe2JqQJtIL5KQ0oYWB1GjNQTylYYmyh 6Cmlca0kMpZpF8WyBsvcMtRlFnHZN00sa1rna57rqQlAg6yvearR6FyzxcM74LajeDTJLGpT CTzsrPZpWU0r8LjOTnIq7GrSxlqLBoHLLEDsrDpFHXM+VtTrmoP7JJaOY3Z000Ik0WxFrJDo juKFN6EWKwnwFLoEhbr0Y3Efdpl5DbTncjAVhJp3Go5oWnyiGlw2bZiyRgzYZI2gI/he8kjk qqQWAaM1cYrXdrmeoakBw1N5tRAjBbmFEekE7JzBY4CGXhZGO1la6y/JMbtT9kd0gL7L3kQQ tQ9KbaZZxVkWitmRZmlOEEhg1pAEEhkog8RRFX4DlzeDD0SpdNUHT7rAExDcjjCM9I7JygFV ejrxmPi1XRxlj1WKpEFpbPmNVXFbRV4JgxoNdQvaEUTOdi7GSi1sjIRf4AYl6rVJLCfUe70y lVGV+DS5ip3rjtoy2LTb1WEk/G/2zlMiYOdQ2jAUEGdZloFpQke5i6IkS+bQSunkocEPwgRC knYwlh61zRaGB4BEloXuTPtSZ8CVCyqvFVLL60Xpx+d81UpWdp5KDGbxTHZHymEg2cu1ChkB tSpmoqMJcoCdM6/YMLlFUCNTt0YwYCP42g8nUKtphr+PQluPZ68K2FzZ1KQQCa1zVT2EHCod bZCSD1kMbvAj3+2aESmHSGz7ZnpeURfHsaUhwODhz0FsMS76y27V6vUY2OANWYOh9ozdmBFR Jpw1otrN2c147aS22m8Te7UeMGAVtYN+BhsA4CLPYQKv4s8W63MKezzwcdmORshtG+6QY6rz Y5I6Dhl9QxD2RZzuvSMBoJDA7XDA1w5fDE8zf5GLJuHEIIKpljvbNugMsIhks8Zp6XFS+KQX qb4pSJtHUXpMgLztQiasCVegrgmJgZiZqQBiTA2DfGEKBtYl6gzUVSba5vEU+9VLZpVVtVKq rpz86RcqbzKQdeqD2DCwlCbbFDNtkS0IrgQTSYi1NLvRgZNN+kPUFbRF3jgkNjXcQfDcZ8wu jmN4vz219m1IMhGEOohtRY9WXN/bOAz08R9QdR2aEBJjJkSZJGs1JE0Qhwxl9mgq4lCmd5IW xaZaUkll43RQYDOiMfxt+FI4LVkcfLtI7UbsdNOJSUG4RQgFPaD2ViHNQQcqyEIkbAEaI+D7 aT6EXDEqtSZgci0CqFRg7TSQM7JuDKQiBRGsdDCplkRV8G2QokvFC7epKlsQRYrwlfIc6bxQ su4MAk8WlejQUUO9gosVVc9GWvfOlmOFmdil+CjSF3UsLQslgq1oJzLlrKhRlje+RTTzMUqF EKiFaVUMYw4NZJB6GfsEz7bCRgIPdDNVqKvoblpYuNwtFuTkGGkEdDW7jJQaWUHBhCGRczID IJM8Ka0oaJsq7hDZ27QLgiiEsBCJAehXa7phadcJWKWQ4o2EDKFgsUVRgqXZuQvAtMCrwFnh VWscHJLMXQbCsTcgJ1DqcZINbTjuc2HWO0VOfYJYZmQVpWSnMZFUop7JBmUxhRnIVBWqK8F5 T/28nx+NeGeVqYhHlK4RpNjQ39hPpNEyCHKRiVRUUYC9Ayu2xIHYHf9ddlBgXQGRMNvfJSLY N1C1dv6P5mbQ3+PHcbndtPbBBf+ChniH5nUQDFpLrn8wpu+KmKpSiIOIPALbWps2XfcOLr7t 6cbxD5HKuKvSDCKpX3HfrO8Msr/EVI5Hf91PaNIS+bhJiW8GfUZ8wKIhe3NwOojxBBJ4PHOg RIzIMbRyymaqeYiDicqCtEHcZNB44pb5S2o7J+25R0Sjsdu5C2joAE+KiLQT1ohUHuRGSUio KrGFUQWEApkMYX46sS+qwVkZKmxbEAQTONXKAkSUda9GVFVhBQM0aPSN5ZOqjTUVPwlTbUrJ U8wfGVS9QVX4MtYxsNAwoZIQQw+dzFBWaiesN5BNFGJDTCgkJvvXPrRW8qeaRH2pgGTEDBnB CiQ9eC61VZASKMIiFedSF1V7cmWydInBFmudiCxcfv1uWeY/Vyrgjk5g07xzqrERbkO0rHwt ng05jESw8EVAla9ubomONIsulV5CRAishTcgpk4HhxpO3vDixHhBEPoQEjkkWGBuxghjV8Ih ruzxJ9LRvZX7DEffMlhiokhsSfc5jSHhq1TMkNMFvLoLCIPiSitTAW4zV1GGYbXvZgQ1y4Tn XVGgA14Fi1LFIzYNJpm1wEoAiYMT17CbYSHCFqu0CaEVKosJKKcEhggsT3K9UqZ0PyldYbiq opBkQWk7oITjX54bBjMCGBnDhBaWObgxaWxIbcStsNRh7WtSToVSpXSk6kzrETRRILkXVIGT GpDGkTQZYSupUS+9PiWTUkTkvumiaEWAXCC9BIzMjOhDyZE2RQWnD0EsKZzJip5bsOyQSVMA oreC4oR6xqVSSoVzkmrYIGNKYSBoZ0zUFRYAemqieYXFjA6Bq1lAbcnerUrV0lUiJ3q8qJGQ yq0eC7Q4qxcTC7z1BBSYcobEhQ00Gl5K/gTJsYI2UNA9VG0AcS6LEakktbd0a0L1QtCH/Nkc BJNNayNQjTKsiYQHioMl0d3wJLnh/rnqvTDd4DjsBniuAJ0x7SOAwDFgtahmvJeBTvy9F95I CMBSpFkK7kiJGA2zZHaWP+QtSD7mbDmQW//IV5KYIMEHbHd0x2uD2ZngVb6sGw/WifgqUHH0 CRIodpSZaDaTOQRVtlgbAuL7oNVJSmSFpaWTzy5ViizNJyuhw2Diw1yyXSZKxkJVGWBMKUUO xlFU7ZFS/uNSfmIZaeQqADMULa7HJtBWMANsf+PrPP53/oN8o+Q3V0xPWVg+TayXv9HhJAGy LuSKcKEgkzAWCg== --------------000704030300080804030201--

1 0

Re: (ITS#7250) Issue with search filter escape sequanced
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

On 04/18/2012 02:47 PM, malleswari.nandi(a)gmail.com wrote: > Full_Name: Malleswari Nandireddy > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.126.170.20) > > > In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry > to LDAP and to search and entry in the LDAP. > > If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using > ldap_search_ext_s , it is not returning any records. > > But when I try to search using ldapsearch , after replacing escape charecter "*" > in the string with "\2a" it is returning records. > > ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' > 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' > > We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , > but it is not returning any records. > > Please help me searching records in LDAP using ldap_search_ext_s() if the filter > has escape charecters like "*,(,)....). You're clearly missing the point between escaping in shell and in C code. However this is a user error, not an (Open)LDAP bug, so I suggest you direct your question to openldap-technical(a)openldap.org; this ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7250) Issue with search filter escape sequanced
by malleswari.nandi＠gmail.com 18 Apr '12

18 Apr '12

Full_Name: Malleswari Nandireddy Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.126.170.20) In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry to LDAP and to search and entry in the LDAP. If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using ldap_search_ext_s , it is not returning any records. But when I try to search using ldapsearch , after replacing escape charecter "*" in the string with "\2a" it is returning records. ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , but it is not returning any records. Please help me searching records in LDAP using ldap_search_ext_s() if the filter has escape charecters like "*,(,)....).

1 0

(ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Enabling memberof overlay on frontend database causes slapd to SEGFAULT due to stack overflow when renaming an entry. Slapd should not segfault even if the configuration is wrong. Initial server configuration: (slapadd -F /etc/openldap/slapd.d -n 0 -l slapd.ldif) dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd.args olcPidFile: /var/run/slapd.pid dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq Initial data: (ldapadd -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data.ldif) dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization o: Example Org dc: my-domain dn: cn=Manager,dc=my-domain,dc=com objectclass: organizationalRole cn: Manager dn: ou=users,dc=my-domain,dc=com objectclass: organizationalUnit ou: users dn: cn=foo,ou=users,dc=my-domain,dc=com objectclass: organizationalRole cn: foo Enabling overlay: (ldapadd -c -Y EXTERNAL -H ldapi:/// -f data_overlays.ldif) dn: olcOverlay={0}memberof,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: error olcMemberOfDanglingError: constraintViolation olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf Renaming the entries, causing segmentation fault: (ldapmodify -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data_modify.ldif) dn: cn=foo,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=bar deleteoldrdn: 1 dn: cn=bar,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=foo deleteoldrdn: 1 Server backtrace: (gdb) bt 6 full #0 0x000000000044f188 in backend_check_restrictions (op=0x0, rs=0x0, opdata=0x0) at ../../../servers/slapd/backend.c:1022 restrictops = 140737153878880 requires = 4515244 opflag = 8413346912 exopflag = 140737311768104 ssfs = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0xa0bc30 updateop = 0 starttls = 0 session = -184966544 #1 0x000000000043f3cf in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:370 bd = 0x7ffff4f9a180 #2 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffec104b60, on=0x0) at ../../../servers/slapd/backover.c:671 func = 0x8dc018 rc = 32768 #3 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 oi = 0x7fffec104b60 on = 0x7fffec104d40 be = 0xa0bc30 db = {bd_info = 0x8dbfc0, bd_self = 0xa0bc30, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 67848, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xa16380, be_nsuffix = 0xa163b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0xa16450 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0xa164a0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0xa16320 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbefb60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8d4c60, be_private = 0xa11e80, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff4f9a410, sc_response = 0x4d8d5b <over_back_response>, sc_cleanup = 0, sc_private = 0x7fffec104b60} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 No locals. #5 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 bd = 0x7ffff4f9a460 (More stack frames follow...) ... #45535 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45536 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45537 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 #45538 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45539 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45540 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45541 0x00000000005abaeb in memberof_isGroupOrMember (op=0x7fffec000940, mci=0x7fffec001420) at ../../../../servers/slapd/overlays/memberof.c:289 #45542 0x00000000005b00c0 in memberof_res_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/overlays/memberof.c:1513 #45543 0x000000000045262c in slap_response_play (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:507 #45544 0x0000000000452868 in send_ldap_response (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:582 #45545 0x0000000000453a52 in slap_send_ldap_result (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:860 #45546 0x000000000050e0a9 in bdb_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #45547 0x00000000004626be in fe_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:314 #45548 0x00000000004d9fd4 in overlay_op_walk (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45549 0x00000000004da225 in over_op_func (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #45550 0x00000000004da3b2 in over_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/backover.c:768 #45551 0x0000000000461e20 in do_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:186 #45552 0x000000000043a9df in connection_operation (ctx=0x7ffff5798b20, arg_v=0x7fffec000940) at ../../../servers/slapd/connection.c:1150 #45553 0x000000000043af9c in connection_read_thread (ctx=0x7ffff5798b20, argv=0x13) at ../../../servers/slapd/connection.c:1286 #45554 0x00000000005d0dd2 in ldap_int_thread_pool_wrapper (xpool=0x9b0170) at ../../../libraries/libldap_r/tpool.c:688 #45555 0x00000034ad607b41 in start_thread (arg=0x7ffff5799700) at pthread_create.c:305 #45556 0x00000034acee0e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> No. Your patch fixes one possible wrong outcome, but the sudo > approach is > still fundamentally wrong and if we only patch this one instance, > someone else > in the future is bound to trip over the sequencing problem again. Fix > the > right bug, otherwise you will have to keep fixing the wrong bugs over > and over > again. OK, thanks for confirmation. I will report a bug for sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

Jan Vcelak wrote: >> Sounds like a simple sequencing bug then. Just initialize the global >> options >> before the first ldap_initialize() call. > > Sudo parses the options in config file and stores them in a table: > http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 > > This table is then iterated and all options are being set. The > problem is that some options are set with LDAP handle provided > and some are not. This means that the handle has to be created > before. The change proposed by you would require the change of > this well-arranged and transparent concept. "Elegance" of code does not make it less wrong. The config is simply driven as a list. They can very easily fix this so that sudo_ldap_set_options() is called twice, first with a NULL ld and only the non-connection-oriented parameters, then create the LDAP handle and call again to set the connection-oriented parameters. > It can be a sequencing bug, but this particular situation is not > described anywhere. Perhaps that should be raised as a separate doc bug then. Global options are copied to a handle at the time the handle is created. Any options not explicitly set globally at that time are set to their default value. > And OpenSSL has a different behavior. My patch > updates Mozilla NSS backend to behave the same as OpenSSL backend. > I still think this should be fixed in OpenLDAP rather than in sudo. No. Your patch fixes one possible wrong outcome, but the sudo approach is still fundamentally wrong and if we only patch this one instance, someone else in the future is bound to trip over the sequencing problem again. Fix the right bug, otherwise you will have to keep fixing the wrong bugs over and over again. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> Sounds like a simple sequencing bug then. Just initialize the global > options > before the first ldap_initialize() call. Sudo parses the options in config file and stores them in a table: http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 This table is then iterated and all options are being set. The problem is that some options are set with LDAP handle provided and some are not. This means that the handle has to be created before. The change proposed by you would require the change of this well-arranged and transparent concept. It can be a sequencing bug, but this particular situation is not described anywhere. And OpenSSL has a different behavior. My patch updates Mozilla NSS backend to behave the same as OpenSSL backend. I still think this should be fixed in OpenLDAP rather than in sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch > Submission from: (NULL) (209.132.186.34) > > > Hello. > > With Mozilla NSS crypto backend, the 'tls_checkpeer no' option in 'sudo' tool > does not work. I have uploaded a patch which fixes the bug. > > But some explanation is necessary: > > sudo initially creates a ldap handle using ldap_initialize() function. Then it > uses ldap_set_option() to set all the settings. The TLS configuration is applied > without passing a LDAP handle, which means the the global options are changed. Sounds like a simple sequencing bug then. Just initialize the global options before the first ldap_initialize() call. > In ldap_int_start_tls(): > > - The ldap_int_tls_connect() is called and the global TLS context is used > (LDAP_INT_GLOBAL_OPT()->ldo_tls_ctx). Which is correct. > > - The ldap_pvt_tls_check_hostname() is called always. "sudo" will set the > ldo_tls_require_cert in global options to LDAP_OPT_X_TLS_NEVER, but the handle > options (ld->ld_options) are used to check whether the verification is supposed > to happen. And ldo_tls_require_cert in handle options is LDAP_OPT_X_TLS_DEMAND > (the default), because it was copied from the global options at the time when > ldap_initialize() was called. > > - With OpenSSL, hostname check (tlso_session_chkhost) will succeed because > tlso_get_cert() will return NULL. This is true because no certificate was > requested when connecting. We do not request the certificate as well in Mozilla > NSS, but it seems that the peer can send it anyway and the library will accept > and store it. In this case, hostname check (tlsm_session_chkhost) might fail > because SSL_PeerCertificate() will return it. > > I've added an additional check, which skips the hostname verification within > tlsm_session_chkhost if we do not request the certificate validation. With this > patch, the behavior is consistent with OpenSSL. > > (Maybe ldap_pvt_tls_check_hostname() should not just be called, because the > global context was used and therefore we should use global options. Not sure > what is expected, but I think that changing this might break some applications. > My fix is safer.) > > Jan > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7110) cn=config mixes values
by hyc＠symas.com 18 Apr '12

18 Apr '12

Raphaël Ouazana-Sustowski wrote: > Sorry, that was a typo. > >>> Case 2 (inversed values): >>> >>> dn: olcDatabase={3}bdb,cn=config >>> changetype: modify >>> replace: olcAccess >>> olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> >>> Result: >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write >>> >>> The two last values are incorrectly mixed. >> >> Wrong, this works as designed. See draft-chu-ldap-xordered-xx section >> 3.3. > > I reread intensively this section (xx=00), but I don't find anywhere > where it is specified that lines are read one after one and not > globally. >>>> The ordering-prefix may also be used in Modification requests to specify which values to delete, and in which position values should be added. When processing deletions and insertions, all of the ordinals are recounted after each individual modification. If a value being added does not have an ordering-prefix, it is simply appended to the list and the appropriate ordering-prefix is automatically generated. Likewise if an ordering-prefix is provided that is greater than or equal to the number of existing values. <<<< > Anyway this is not a problem anymore in my software, I modified the > client to send the values in the good order. But I'd like to understand > where it is specified. Else I think this sample case should be added to > the draft. > > Regards, > Raphaël Ouazana. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Oh, and I forgot: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Rene Snajder Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Full_Name: Rene Snajder Version: 2.4.30 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch Submission from: (NULL) (193.171.77.1) I reported (from my other e-mail address dermaniac(a)gmail.com) a bug report in January. I reported it to the technical mailing list first: http://www.openldap.org/lists/openldap-technical/201201/msg00233.html which I got no reply on. I then posted a ticket here: http://www.openldap.org/its/index.cgi/Incoming?id=7130;page=12 which I got one reply but it didn't fix my problem (and I didn't get further replies). I then took matters in my own hand and found 3 bugs in back-sql which lead to errors when UPPER is applied to integer values. Since there was no reaction here I tried to report it to Redhat (since I'm using RHEL) where the issue finally got some attention. I created a bugfix and they advised me to submit it directly to openldap, so now I'm trying it here again. Strangely, the same day that redhat responded to my patch I got a reply here: http://www.openldap.org/lists/openldap-technical/201204/msg00108.html to which I cannot seem to answer (my mails to the mailing list never seem to make it through). Here are the bugs that I found: 1) It is not checked whether the UPPER function can be applied on a type in the database. Comments in the code itself confirm that this is "currently broken". (see my previous 2 comments) 2) One would assume that the parameter "upper_needs_cast yes" in the slapd.conf would add a string casting statement to every UPPER statement in the SQL queries. In fact, it only does so for one single query (when it queries for "ldap_entries.dn"). All other queries where UPPER is applied still don't use a cast, even though I declare "upper_needs_cast yes" in the main config file. 3) The slapd.conf file lets me declare a "strcast_func" which is the name of the function for a cast to string. This strcast_func is used at some points in the queries, but not consistently. For the one query that actually pays any attention to the "upper_needs_cast" parameter (which i mentioned before) a hardcoded string cast function is used instead. This function is always "(cast ? as varchar(255))". Now these are 3 separate problems in the back-sql code. To fix my particular problem I took a closer look at problem number 2. I attached an patch which can be applied to the version in the GIT repository. When this patch is applied, the hardcoded strcast function from problem number 3 is at least applied to every use of the UPPER function (or at least everywhere where the upper function is applied properly!), effectively fixing problem number 2. This may THEORETICALLY lead to the following problem: IF someone set "upper_needs_cast yes" in their config, with a database backend that does not support the hardcoded strcast function, this patch would break the SQL queries for this user. BUT, in that case using the "upper_needs_cast yes" statement would have been useless - or even causing problems - before this patch anyways - since it was always using the hardcoded function and only at one single point. My patch is here: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch For a more detailed description see my bug report in the Redhat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=809105

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

Howard Chu wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> 4.2.2.2 fedfsFsn >>> IMO name/port should just be an LDAP URL. Also your definition provides >>> absolutely zero information of how the LDAP server should be contacted (e.g. >>> using ldaps or StartTLS) which both can be encoded in an LDAP URL. >> >> Which standard describes how to mandate use of StartTLS with a LDAP URL? >> OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with >> web2ldap. But AFAIK this is not defined in any standard which could be >> referenced in a RFC. > > True but irrelevant. The point is that standardizing on a URL syntax today > future-proofs a spec and allows it to handle new connection mechanisms that > may appear in the future. Host/port is inextricably tied to networking in the > 1980s. I did not want to endorse the use of host/port. I just wanted to point out that one cannot specify the use of StartTLS by LDAP URL in a standard way. Of course nothing prevents somebody to add custom extension to LDAP URLs. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs