openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

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

20 Apr '12

> OK, thanks for confirmation. I will report a bug for sudo. http://www.sudo.ws/bugs/show_bug.cgi?id=554

1 0

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

20 Apr '12

Kurt(a)OpenLDAP.org wrote: > On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > >> 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. > > Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. Thanks for the confirmation. The text of RFC2891 seems contradictory here though. Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891? -- -- 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#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > 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. Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. -- Kurt

1 0

(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 20 Apr '12

20 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 20 Apr '12

20 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

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012