- openldap-bugs - openldap.org

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 8:25 AM, kurt(a)openldap.org wrote: >> which use the sss >> control on standards attributes like cn or sn. > > maybe you should file a bug report with them. and I should note that I consider most client use of this control, itself, to be a bug. Client's really should, in general, just do their own sorting over the result set, especially for sorting entries for presentation purposes. The only case where I see this control being useful is, in conjunction with the paged results control, for asking for the entry with the lowest/highest single-valued serial number (or like) attributes. -- Kurt

1 0

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

20 Apr '12

We seem to be two guys discussing work we're not volunteering to do anytime soon, but anyway... On Fri, 20 Apr 2012 07:22:32 GMT, masarati(a)aero.polimi.it wrote: > On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote: >> 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. Actually one simpler but uglier macro is enough, without touching non-internal calls: /* * Do ACT with OP->o_internal set. * Example: WITH_INTERNAL_OP( op, rc = op->o_bd->be_add( op, rs )); */ #define WITH_INTERNAL_OP(op, act) do { \ int *const wio_intern_ = &(op)->o_internal; \ int const wio_save_ = (*wio_intern_)++; \ act; \ (*wio_intern_)--; \ assert(*wio_intern_ == wio_save_); /* Keep this while testing */ \ } while (0) Not my preference, but at least it's an option. >> 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? If I were doing it, I'd play in a separate branch while getting a feel for how it'll end up. Never mind the exact API, it can be rewritten at this stage if it's unsufficient or overkill. Then give master whatever framework is neeed to allow the rest of the job to be done some operation calls at the time, without needing a monster commit to develop and review. Technically, if not just the wrapper macro above: > 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. Fair enough. 0/1 could be enum constants, but that's more verbose. And it's just 6 macros for now: My 3 old plus 3 new. /* In proto-slap.h: */ #define slap_bi_op( bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op, rs)) #define slap_be_op( be,which,op,rs) slap_bi_op( (be)->bd_info,which,op,rs) #define SLAP_OP( which,op,rs) slap_be_op( (op)->o_bd, which,op,rs) /* Internal operations - as above but with op->o_internal set */ LDAP_SLAPD_F (int) (slap_bi_intop) LDAP_P(( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs )); #define slap_be_intop(be,which,op,rs) slap_bi_intop((be)->bd_info,which,op,rs) #define SLAP_INTOP( which,op,rs) slap_be_intop(&(op)->o_bd, which,op,rs) /* In backend.c: */ int slap_bi_intop( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs) { int rc; WITH_INTERNAL_OP( rc = slap_bi_op( bi, which, op, rs )); return rc; } > At this point, we need consensus on addressing ITS#6758 in the first > place. Nah. ITS#6758 needs the macros (at least if I'm to go at it), but the macros don't need ITS#6758 since they don't change what the code does. 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 Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 7:56 AM, clem.oudot(a)gmail.com wrote: > 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. maybe you should file a bug report with them. > May it be possible to add an option in the sssvlv overlay to ignore such errors? I prefer not to condone non-standard behaviors by adding workarounds for them.

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 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

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

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

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

18 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 17 Apr '12

17 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

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

16 Apr '12

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. > http://www.openldap.org/lists/openldap-devel/200202/msg00060.html > http://www.openldap.org/lists/openldap-devel/200810/msg00034.html > > Ciao, Michael. > -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

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. http://www.openldap.org/lists/openldap-devel/200202/msg00060.html http://www.openldap.org/lists/openldap-devel/200810/msg00034.html Ciao, Michael.

1 0

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

16 Apr '12

On Apr 16, 2012, at 1:09 PM, Howard Chu wrote: > chuck.lever(a)oracle.com wrote: >> Full_Name: Chuck Lever >> Version: All >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.26.161.222) >> >> >> I'd like to request the addition of the FedFS schema described in this draft: >> >> http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 >> >> as part of the repertoire of schemas that are installed by default for new >> servers. An overview of FedFS can be found here: >> >> http://tools.ietf.org/html/rfc5716 >> >> I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >> >> http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif > > This gets a 404 for me. > >> This contains the correct IETF boilerplate. The schema is extracted verbatim >> from draft 11. >> >> Addendum: The NSDB draft is in last call, and there have been some changes to >> the schema. I will provide a refresh as soon as the next revision of the draft >> is available. > > From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. > > 4.1 > fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. > > 4.2.1.1 > I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". > > 4.2.1.2/3 > IMO you should define a URL format instead of distinct address/port attributes. > > 4.2.1.14 > XDR blobs? Really? The point of XDR blobs is that a file server doesn't need to un-marshall then re-marshall the pathname data when it generates a referral. Replacement suggestions welcome. > 4.2.1.18... > Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. > > 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. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. > > I haven't read the rest of the draft but IMO this is premature for a last call. This draft has been in last call for months, I'm surprised there are so many issues. I think there is still an opportunity for discussion on the working group mailing list. We welcome your comments on nfsv4(a)ietf.org. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

(ITS#7247) smbk5pwd.c: hdb_generate_key_set_password function changes
by quanah＠OpenLDAP.org 16 Apr '12

16 Apr '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the Debian bug tracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664930 The cause of the problem is that a function declared in a header file in the heimdal package has changed its signature. The old header said: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, Key **/*keys*/, size_t */*num_keys*/); The new version says: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, krb5_key_salt_tuple */*ks_tuple*/, int /*n_ks_tuple*/, Key **/*keys*/, size_t */*num_keys*/);

1 0

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

16 Apr '12

Corrected URL: http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

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

16 Apr '12

chuck.lever(a)oracle.com wrote: > Full_Name: Chuck Lever > Version: All > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.26.161.222) > > > I'd like to request the addition of the FedFS schema described in this draft: > > http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 > > as part of the repertoire of schemas that are installed by default for new > servers. An overview of FedFS can be found here: > > http://tools.ietf.org/html/rfc5716 > > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: > > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This gets a 404 for me. > This contains the correct IETF boilerplate. The schema is extracted verbatim > from draft 11. > > Addendum: The NSDB draft is in last call, and there have been some changes to > the schema. I will provide a refresh as soon as the next revision of the draft > is available. From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. 4.1 fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. 4.2.1.1 I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". 4.2.1.2/3 IMO you should define a URL format instead of distinct address/port attributes. 4.2.1.14 XDR blobs? Really? 4.2.1.18... Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. 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. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. I haven't read the rest of the draft but IMO this is premature for a last call. -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030305020403080208020708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable chuck.lever(a)oracle.com wrote: > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >=20 > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This link does not work: HTTP/1.1 404 Not Found > This contains the correct IETF boilerplate. The schema is extracted ve= rbatim > from draft 11. >=20 > Addendum: The NSDB draft is in last call, and there have been some cha= nges to > the schema. I will provide a refresh as soon as the next revision of t= he draft > is available. I really wonder why 'fedfsUuid' is SUP name instead of being based on LDA= P syntax UUID (see RFC 4530). Ciao, Michael. --------------ms030305020403080208020708 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxNjE2MzUxN1owIwYJKoZIhvcNAQkEMRYE FJYm4uvB6dO0Xfb+VWGOiUGFmjzuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAXr+lTSmYWrS1gIcELAxFI1MQ2sMnWAtCIkDhV++q2rtHIxv3FMtGDZMVrpVUUJpmLtfM S8qRyiP23ceohvePmIKviVd+imlCn0wYjTYirg2+BVgjt5NyaA1pT7C5GbjcfF5o7+Fbroy3 5wrk+S+P+EjMqT3XLuvVKeWDYN/5pea8kv0QGnFj2xkkRaNFSX1zwsjAzBRuqcRi8M5/DwIg YvUI2oefNktzAOYxW6LGn0YQxQ+WhJj+BzKbwYViiQsRCZR8h6EHSbUzqMC6DZz3NXMkdp4i dlyR0f00tcfu92e7TINj2c/eCbfLrDEA4YqUwUA2yCsx/D5n3Kp/Ln3ilgAAAAAAAA== --------------ms030305020403080208020708--

1 0

(ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

Full_Name: Chuck Lever Version: All OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.26.161.222) I'd like to request the addition of the FedFS schema described in this draft: http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 as part of the repertoire of schemas that are installed by default for new servers. An overview of FedFS can be found here: http://tools.ietf.org/html/rfc5716 I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This contains the correct IETF boilerplate. The schema is extracted verbatim from draft 11. Addendum: The NSDB draft is in last call, and there have been some changes to the schema. I will provide a refresh as soon as the next revision of the draft is available.

1 0

Re: (ITS#7245) crash when using CSN in cookie
by hyc＠symas.com 16 Apr '12

16 Apr '12

jsoula(a)univ-lille2.fr wrote: > Full_Name: julien soula > Version: 2.4.30 > OS: gentoo/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.254.117.85) > > > hello, > > on a replica, when I use cookie parameter with csn value as : > -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' > the server crash immediately du to bad free : Thanks for the report, fixed in git master. > > #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 > #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 > #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 > #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 > #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at > memory.c:731 > #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 > #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, > free_cookie=1) > at ldapsync.c:106 > #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:675 > #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > After some analyzes, I noticed that the allocation of this block was done with a > not null memory context : > > #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 > #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, > ctx=0xd3ebd0) at memory.c:506 > #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, > val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) > at schema_init.c:5395 > #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, > memctx=0xd3ebd0) > at ldapsync.c:342 > #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:671 > #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > but was freed with a null context as seen above. > > If I modify the code to force a null context allocation, it works. > > PS: I shortly took a look at Git code and it seems to be the same. > > Best regards, -- -- 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

(ITS#7245) crash when using CSN in cookie
by jsoula＠univ-lille2.fr 16 Apr '12

16 Apr '12

Full_Name: julien soula Version: 2.4.30 OS: gentoo/linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.254.117.85) hello, on a replica, when I use cookie parameter with csn value as : -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' the server crash immediately du to bad free : #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at memory.c:731 #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, free_cookie=1) at ldapsync.c:106 #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:675 #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 After some analyzes, I noticed that the allocation of this block was done with a not null memory context : #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, ctx=0xd3ebd0) at memory.c:506 #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) at schema_init.c:5395 #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, memctx=0xd3ebd0) at ldapsync.c:342 #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:671 #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 but was freed with a null context as seen above. If I modify the code to force a null context allocation, it works. PS: I shortly took a look at Git code and it seems to be the same. Best regards, -- Julien

1 0

Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by hyc＠symas.com 14 Apr '12

14 Apr '12

napalaniappan(a)paypal.com wrote: > --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Thanks a lot for the information. I have the following configurations, coul= > d you check and help me to fix the NSS config. No. You've been told multiple times that this is not the place to ask these questions. -- -- 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#7243) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠paypal.com 14 Apr '12

14 Apr '12

--_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot for the information. I have the following configurations, coul= d you check and help me to fix the NSS config. # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=3Dreturn]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # ldap Use LDAP (only if nss_ldap is installed) # nisplus or nis+ Use NIS+ (NIS version 3), unsupported # [NOTFOUND=3Dreturn] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files ldap nis #shadow: db files ldap nis #group: db files ldap nis passwd: files shadow: files group: files #hosts: db files ldap nis dns hosts: files dns # Example - obey only what ldap tells us... #services: ldap [NOTFOUND=3Dreturn] files #networks: ldap [NOTFOUND=3Dreturn] files #protocols: ldap [NOTFOUND=3Dreturn] files #rpc: ldap [NOTFOUND=3Dreturn] files #ethers: ldap [NOTFOUND=3Dreturn] files bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: files automount: files aliases: files [root@ppdoldap01 etc]# uptime 18:02:10 up 230 days, 10:53, 2 users, load average: 0.95, 0.98, 0.92 [root@ppdoldap01 etc]# more nscd.conf # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # Legal entries are: # # logfile <file> # debug-level <level> # threads <initial #threads to use> # max-threads <maximum #threads to use> # server-user <user to run server as instead of root> # server-user is ignored if nscd is started with -S parameter= s # stat-user <user who is allowed to request statistics> # reload-count unlimited|<number> # paranoia <yes|no> # restart-interval <time in seconds> # # enable-cache <service> <yes|no> # positive-time-to-live <service> <time in seconds> # negative-time-to-live <service> <time in seconds> # suggested-size <service> <prime number> # check-files <service> <yes|no> # persistent <service> <yes|no> # shared <service> <yes|no> # max-db-size <service> <number bytes> # auto-propagate <service> <yes|no> # # Currently supported cache names (services): passwd, group, hosts # # logfile /var/log/nscd.log # threads 6 # max-threads 128 server-user nscd # stat-user nocpulse debug-level 0 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 [etc]# cat libuser.conf # This is a first-generation configuration file. Eventually I'll rewrite # all of the configuration-reading code to use alchemist, but for now this # will have to do. # Do not modify the default module list if you care about unattended calls # to programs (i.e., scripts) working! [defaults] # The default (/usr/lib*/libuser) is usually correct # moduledir =3D /your/custom/directory skeleton =3D /etc/skel mailspooldir =3D /var/mail modules =3D files shadow create_modules =3D files shadow crypt_style =3D md5 # modules =3D files shadow ldap krb5 # create_modules =3D ldap krb5 [userdefaults] LU_USERNAME =3D %n LU_UIDNUMBER =3D 500 LU_GIDNUMBER =3D %u # LU_USERPASSWORD =3D !! # LU_GECOS =3D %n # LU_HOMEDIRECTORY =3D /home/%n # LU_LOGINSHELL =3D /bin/bash # LU_SHADOWNAME =3D %n # LU_SHADOWPASSWORD =3D !! # LU_SHADOWLASTCHANGE =3D %d # LU_SHADOWMIN =3D 0 # LU_SHADOWMAX =3D 99999 # LU_SHADOWWARNING =3D 7 # LU_SHADOWINACTIVE =3D -1 # LU_SHADOWEXPIRE =3D -1 # LU_SHADOWFLAG =3D -1 [groupdefaults] LU_GROUPNAME =3D %n LU_GIDNUMBER =3D 500 # LU_GROUPPASSWORD =3D !! # LU_MEMBERUID =3D # LU_ADMINISTRATORUID =3D [files] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [shadow] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [ldap] # Setting these is always necessary. # server =3D ldap # basedn =3D dc=3Dexample,dc=3Dcom # Setting these is rarely necessary, since it's usually correct. # userBranch =3D ou=3DPeople # groupBranch =3D ou=3DGroup # Set only if your administrative user uses simple bind operations to # connect to the server. # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom # Set this only if the default user (as determined by SASL) is incorrect # for SASL bind operations. Usually, it's correct, so you'll rarely need # to set these. # user =3D Manager # authuser =3D Manager [krb5] # Set this only if it differs from the default in /etc/krb5.conf. # realm =3D EXAMPLE.COM # Set this only if the default (currentuser/admin) will be incorrect. # principal =3D example/admin(a)EXAMPLE.COM [sasl] # Set these only if your sasldb is only used by a particular application, a= nd # in a particular domain. The default (all applications, all domains) is # probably correct for most installations. # appname =3D imap # domain =3D EXAMPLE.COM -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file! > Full_Name: Natarrajan > Version: 2.2.13-7.4E > OS: RHEL4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.113.168.128) > > > I am getting the following error frequently in my ldap client machine. > > LDAPCLIENT ~> whoami > whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv > ls > sudo: uid 14281 does not exist in the passwd file! > > Let me know the fix for the issue. Upgrade (2.2.13 is about 10 years old now; 2.4.30 is the current release). Then, fix the configuration of your nss? p. --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ 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-micr= osoft-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=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Thanks a lot for the information. I have the foll= owing configurations, could you check and help me to fix the NSS config.<o:= p></o:p> <o:p> </o:p> # /etc/nsswitch.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Switch config file. Thi= s file should be<o:p></o:p> # sorted with the most-used services at the begin= ning.<o:p></o:p> #<o:p></o:p> # The entry '[NOTFOUND=3Dreturn]' means that the = search for an<o:p></o:p> # entry should stop if the search in the previous= entry turned<o:p></o:p> # up nothing. Note that if the search failed due = to some other reason<o:p></o:p> # (like no NIS server responding) then the search= continues with the<o:p></o:p> # next entry.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       nis or yp&n= bsp;           &nbsp= ;  Use NIS (NIS version 2), also called YP<o:p></o:p> #       dns  &= nbsp;           &nbs= p;      Use DNS (Domain Name Service)<o:p></o= :p> #       files =             &nb= sp;     Use the local files<o:p></o:p> #       db &nb= sp;            =         Use the local database (.db) fil= es<o:p></o:p> #       compat&nbsp= ;            &n= bsp;    Use NIS on compat mode<o:p></o:p> #       hesiod&nbsp= ;            &n= bsp;    Use Hesiod for user lookups<o:p></o:p> #       ldap &= nbsp;           &nbs= p;      Use LDAP (only if nss_ldap is installed)<o= :p></o:p> #       nisplus or = nis+         Use NIS+ (NIS = version 3), unsupported<o:p></o:p> #       [NOTFOUND= =3Dreturn]       Stop searching if not found = so far<o:p></o:p> #<o:p></o:p> <o:p> </o:p> # To use db, put the "db" in front of &= quot;files" for entries you want to be<o:p></o:p> # looked up first in the databases<o:p></o:p> #<o:p></o:p> # Example:<o:p></o:p> #passwd:    db files ldap nis<o:p>= </o:p> #shadow:    db files ldap nis<o:p>= </o:p> #group:     db files ldap nis= <o:p></o:p> <o:p> </o:p> passwd:     files<o:p></o:p><= /p> shadow:     files<o:p></o:p><= /p> group:      files<o:p></= o:p> <o:p> </o:p> #hosts:     db files ldap nis= dns<o:p></o:p> hosts:      files dns<o:= p></o:p> <o:p> </o:p> # Example - obey only what ldap tells us...<o:p><= /o:p> #services:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #networks:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #protocols: ldap [NOTFOUND=3Dreturn] files<o:p></= o:p> #rpc:       ldap [N= OTFOUND=3Dreturn] files<o:p></o:p> #ethers:    ldap [NOTFOUND=3Dretur= n] files<o:p></o:p> <o:p> </o:p> bootparams: files<o:p></o:p> ethers:     files<o:p></o:p><= /p> netmasks:   files<o:p></o:p> networks:   files<o:p></o:p> protocols:  files<o:p></o:p> rpc:        fi= les<o:p></o:p> services:   files<o:p></o:p> netgroup:   files<o:p></o:p> publickey:  files<o:p></o:p> automount:  files<o:p></o:p> aliases:    files<o:p></o:p> [root@ppdoldap01 etc]# uptime<o:p></o:p> 18:02:10 up 230 days, 10:53,  2 users, = load average: 0.95, 0.98, 0.92<o:p></o:p> [root@ppdoldap01 etc]# more nscd.conf<o:p></o:p><= /p> #<o:p></o:p> # /etc/nscd.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Cache config file.&nbsp= ; This file is needed by nscd.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       logfile&nbs= p;            &= nbsp;   <file><o:p></o:p> #       debug-level=              &l= t;level><o:p></o:p> #       threads&nbs= p;            &= nbsp;   <initial #threads to use><o:p></o:p> #       max-threads=              &l= t;maximum #threads to use><o:p></o:p> #       server-user=              &l= t;user to run server as instead of root><o:p></o:p> #        =        server-user is ignored if nscd is star= ted with -S parameters<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  <user who is allowed to request statistics><o:p></o:p> #       reload-coun= t            unlimit= ed|<number><o:p></o:p> #       paranoia&nb= sp;            &nbsp= ;  <yes|no><o:p></o:p> #       restart-int= erval        <time in seconds><o:p= ></o:p> #<o:p></o:p> #       enable-cach= e            <ser= vice> <yes|no><o:p></o:p> #       positive-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       negative-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       suggested-s= ize          <service> &= lt;prime number><o:p></o:p> #       check-files=              &l= t;service> <yes|no><o:p></o:p> #       persistent&= nbsp;           &nbs= p; <service> <yes|no><o:p></o:p> #       shared&nbsp= ;            &n= bsp;    <service> <yes|no><o:p></o:p> #       max-db-size=              &l= t;service> <number bytes><o:p></o:p> #       auto-propag= ate          <service> &= lt;yes|no><o:p></o:p> #<o:p></o:p> # Currently supported cache names (services): pas= swd, group, hosts<o:p></o:p> #<o:p></o:p> <o:p> </o:p> <o:p> </o:p> #       logfile&nbs= p;            &= nbsp;   /var/log/nscd.log<o:p></o:p> #       threads&nbs= p;            &= nbsp;   6<o:p></o:p> #       max-threads=              12= 8<o:p></o:p>        server-= user           &nbsp= ; nscd<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  nocpulse<o:p></o:p>         debug-= level           &nbs= p; 0<o:p></o:p> #       reload-coun= t            5<o:p><= /o:p>         parano= ia            &= nbsp;   no<o:p></o:p> #       restart-int= erval        3600<o:p></o:p> <o:p> </o:p>         enable= -cache            pa= sswd          yes<o:p></o:p></= p>         positi= ve-time-to-live   passwd      &nbsp= ;   600<o:p></o:p>         negati= ve-time-to-live   passwd      &nbsp= ;   20<o:p></o:p>         sugges= ted-size          passwd =          211<o:p></o:p>         check-= files           &nbs= p; passwd          yes<o:p></o= :p>         persis= tent           &nbsp= ;  passwd          yes<o:= p></o:p>         shared=             &nb= sp;     passwd      &nbsp= ;   yes<o:p></o:p>         max-db= -size           &nbs= p; passwd          33554432<o:= p></o:p>         auto-p= ropagate          passwd =          yes<o:p></o:p> <o:p> </o:p>         enable= -cache            gr= oup           yes<o:p></o= :p>         positi= ve-time-to-live   group       =     3600<o:p></o:p>         negati= ve-time-to-live   group       =     60<o:p></o:p>         sugges= ted-size          group &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; group           yes<o:= p></o:p>         persis= tent           &nbsp= ;  group           y= es<o:p></o:p>         shared=             &nb= sp;     group       =     yes<o:p></o:p>         max-db= -size           &nbs= p; group           335544= 32<o:p></o:p>         auto-p= ropagate          group &= nbsp;         yes<o:p></o:p> <o:p> </o:p>         enable= -cache            ho= sts           yes<o:p></o= :p>         positi= ve-time-to-live   hosts       &nbsp= ;   3600<o:p></o:p>         negati= ve-time-to-live   hosts       =     20<o:p></o:p>         sugges= ted-size          hosts &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; hosts           yes<o:= p></o:p>         persis= tent           &nbsp= ;  hosts           y= es<o:p></o:p>         shared=             &nb= sp;     hosts       =     yes<o:p></o:p>         max-db= -size           &nbs= p; hosts           335544= 32<o:p></o:p> <o:p> </o:p> [etc]# cat libuser.conf<o:p></o:p> # This is a first-generation configuration file.&= nbsp; Eventually I'll rewrite<o:p></o:p> # all of the configuration-reading code to use al= chemist, but for now this<o:p></o:p> # will have to do.<o:p></o:p> <o:p> </o:p> # Do not modify the default module list if you ca= re about unattended calls<o:p></o:p> # to programs (i.e., scripts) working!<o:p></o:p>= <o:p> </o:p> [defaults]<o:p></o:p> # The default (/usr/lib*/libuser) is usually corr= ect<o:p></o:p> # moduledir =3D /your/custom/directory<o:p></o:p>= skeleton =3D /etc/skel<o:p></o:p> mailspooldir =3D /var/mail<o:p></o:p> modules =3D files shadow<o:p></o:p> create_modules =3D files shadow<o:p></o:p> crypt_style =3D md5<o:p></o:p> # modules =3D files shadow ldap krb5<o:p></o:p></= p> # create_modules =3D ldap krb5<o:p></o:p> <o:p> </o:p> [userdefaults]<o:p></o:p> LU_USERNAME =3D %n<o:p></o:p> LU_UIDNUMBER =3D 500<o:p></o:p> LU_GIDNUMBER =3D %u<o:p></o:p> # LU_USERPASSWORD =3D !!<o:p></o:p> # LU_GECOS =3D %n<o:p></o:p> # LU_HOMEDIRECTORY =3D /home/%n<o:p></o:p> # LU_LOGINSHELL =3D /bin/bash<o:p></o:p> <o:p> </o:p> # LU_SHADOWNAME =3D %n<o:p></o:p> # LU_SHADOWPASSWORD =3D !!<o:p></o:p> # LU_SHADOWLASTCHANGE =3D %d<o:p></o:p> # LU_SHADOWMIN =3D 0<o:p></o:p> # LU_SHADOWMAX =3D 99999<o:p></o:p> # LU_SHADOWWARNING =3D 7<o:p></o:p> # LU_SHADOWINACTIVE =3D -1<o:p></o:p> # LU_SHADOWEXPIRE =3D -1<o:p></o:p> # LU_SHADOWFLAG =3D -1<o:p></o:p> <o:p> </o:p> [groupdefaults]<o:p></o:p> LU_GROUPNAME =3D %n<o:p></o:p> LU_GIDNUMBER =3D 500<o:p></o:p> # LU_GROUPPASSWORD =3D !!<o:p></o:p> # LU_MEMBERUID =3D<o:p></o:p> # LU_ADMINISTRATORUID =3D<o:p></o:p> <o:p> </o:p> [files]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [shadow]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [ldap]<o:p></o:p> # Setting these is always necessary.<o:p></o:p></= p> # server =3D ldap<o:p></o:p> # basedn =3D dc=3Dexample,dc=3Dcom<o:p></o:p> <o:p> </o:p> # Setting these is rarely necessary, since it's u= sually correct.<o:p></o:p> # userBranch =3D ou=3DPeople<o:p></o:p> # groupBranch =3D ou=3DGroup<o:p></o:p> <o:p> </o:p> # Set only if your administrative user uses simpl= e bind operations to<o:p></o:p> # connect to the server.<o:p></o:p> # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom<o= :p></o:p> <o:p> </o:p> # Set this only if the default user (as determine= d by SASL) is incorrect<o:p></o:p> # for SASL bind operations.  Usually, it's c= orrect, so you'll rarely need<o:p></o:p> # to set these.<o:p></o:p> # user =3D Manager<o:p></o:p> # authuser =3D Manager<o:p></o:p> <o:p> </o:p> [krb5]<o:p></o:p> # Set this only if it differs from the default in= /etc/krb5.conf.<o:p></o:p> # realm =3D EXAMPLE.COM<o:p></o:p> # Set this only if the default (currentuser/admin= ) will be incorrect.<o:p></o:p> # principal =3D example/admin(a)EXAMPLE.COM<o:p></o= :p> <o:p> </o:p> [sasl]<o:p></o:p> # Set these only if your sasldb is only used by a= particular application, and<o:p></o:p> # in a particular domain.  The default (all = applications, all domains) is<o:p></o:p> # probably correct for most installations.<o:p></= o:p> # appname =3D imap<o:p></o:p> # domain =3D EXAMPLE.COM<o:p></o:p> <o:p> </o:p> -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!<= /p> <o:p> </o:p> > Full_Name: Natarrajan<o:p></o:p> > Version: 2.2.13-7.4E<o:p></o:p> > OS: RHEL4.5<o:p></o:p> > URL: <a href=3D"ftp://ftp.openldap.org/incom= ing/">ftp://ftp.openl= dap.org/incoming/</a><o:p></o:p> > Submission from: (NULL) (216.113.168.128)<o:= p></o:p> ><o:p> </o:p> ><o:p> </o:p> > I am getting the following error frequently = in my ldap client machine.<o:p></o:p> ><o:p> </o:p> > LDAPCLIENT ~> whoami<o:p></o:p> > whoami: cannot find name for user ID 14281 L= DAPCLIENT ~> sudo -u qserv <o:p></o:p> > ls<o:p></o:p> > sudo: uid 14281 does not exist in the passwd= file!<o:p></o:p> ><o:p> </o:p> > Let me know the fix for the issue.<o:p></o:p= > <o:p> </o:p> Upgrade (2.2.13 is about 10 years old now; 2.4.30= is the current release).<o:p></o:p> Then, fix the configuration of your nss?<o:p></o:= p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_--

1 0

Re: (ITS#7229) still not fixed
by michael＠stroeder.com 14 Apr '12

14 Apr '12

hyc(a)symas.com wrote: > Your problem is completely unrelated to ITS#7229, which was about an ENOSPC > error. You're getting ENOMEM, which simply means you've exceeded the > configured size of the DB. Yes, forgot setting maxsize. Sorry. Ciao, Michael.

1 0

Re: (ITS#7229) still not fixed
by hyc＠symas.com 14 Apr '12

14 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000002080400040504030402 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > HI! > > I'm testing with RE24 (39fb7afe5f5acb48686a41a11ef57aa72a772626) on openS= > USE > 11.4 x86_64 but I'm still getting this error when loading an accesslog DB= > =2E It > is not fixed yet. > > slapadd: could not add entry dn=3D"reqStart=3D20110131134340.000002Z,cn=3D= > accesslog" > (line=3D270877): txn_aborted! Internal error (80) > 4f897bb9 mdb_id2entry_put: mdb_put failed: Cannot allocate memory(12) > "reqStart=3D20110201074944.000001Z,cn=3Daccesslog" Your problem is completely unrelated to ITS#7229, which was about an ENOSPC error. You're getting ENOMEM, which simply means you've exceeded the configured size of the DB. > The problem is that adding most entries does work but the error happens > occasionally no matter whether -q is used or not. > > Ciao, Michael. -- -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs