openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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 7:54 AM, Hallvard Breien Furuseth wrote: >> (...) >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return >> sortResult.success. Otherwise return sortResult with sortResult != >> success. >> >> This, I think is consistent with RFC 2891. > > Though the new behavior may be formally compatible with both RFCs, > it certainly breaks the expectations of one of them and must do so. Client developers implementing/using RFC 2891 should only have one key expectation: The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. Clients which assume results are otherwise sorted are simply broken. And, more generally, the client developer should not assume servers adhere to all "shoulds" and "SHOULDs" in a spec. > > How long has the previous behavior been in in OpenLDAP? Is it > feasible to delay the change until RE25? Seems like a typical > kind of change to avoid doing in the middle of a release series. As Howard's comment imply, we implement the behavior I suggest... all he's doing is clarifying in comments the current code behaves consistently with both RFC 2891 and RFC 4510. -- Kurt

1 0

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

20 Apr '12

Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit : > Kurt(a)OpenLDAP.org wrote: >> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> 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. >> >> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. >> >>> 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). >> >> Both 3 and 4, especially when taken together, overload criticality. >> >> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. >> >> 4 isn't much better. >> >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. >> >> This, I think is consistent with RFC 2891. >> The client application is assured that the results are sorted in the >> specified key order if and only if the result code in the >> sortKeyResponseControl is success. >> >> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > OK. I'm going to add some comments to this effect in sssvlv.c but otherwise > close this ITS, works as designed. I would like just mention that this choice may be relevant from an RFC/standardization point of view, but will lead to incompatibility of OpenLDAP with some softwares like Cognos or Outlook, which use the sss control on standards attributes like cn or sn. May it be possible to add an option in the sssvlv overlay to ignore such errors? Clément.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by h.b.furuseth＠usit.uio.no 20 Apr '12

20 Apr '12

On Fri, 20 Apr 2012 14:05:34 GMT, Kurt(a)OpenLDAP.org wrote: > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was > the reason why the criticality processing requirements were make more > clear in RFC 4510. Overloading criticality (or any protocol element) > is simply a bad thing. IIRC that was done with the understanding that some control RFCs would have to be rewritten - but apparently nobody volunteered to do the rewrites. > (...) > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return > sortResult.success. Otherwise return sortResult with sortResult != > success. > > This, I think is consistent with RFC 2891. Though the new behavior may be formally compatible with both RFCs, it certainly breaks the expectations of one of them and must do so. How long has the previous behavior been in in OpenLDAP? Is it feasible to delay the change until RE25? Seems like a typical kind of change to avoid doing in the middle of a release series. -- Hallvard

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 6:35 AM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> 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. > > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > >> 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). > > Both 3 and 4, especially when taken together, overload criticality. > > 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. > > 4 isn't much better. > > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. > > This, I think is consistent with RFC 2891. > The client application is assured that the results are sorted in the > specified key order if and only if the result code in the > sortKeyResponseControl is success. > > clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. OK. I'm going to add some comments to this effect in sssvlv.c but otherwise close this ITS, works as designed. -- -- 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 6:35 AM, Howard Chu wrote: > 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. RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > 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). Both 3 and 4, especially when taken together, overload criticality. 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. 4 isn't much better. So the whole specification is a mess. What I recommend is this, If the server implements the control: If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. This, I think is consistent with RFC 2891. The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > 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#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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs