- openldap-bugs - openldap.org

(ITS#6286) auditlog incorrectly prints end of modify operation
by baggins＠sith.mimuw.edu.pl 07 Sep '09

07 Sep '09

Full_Name: Jan Rekorajski Version: 2.4.17 OS: Linux PLD URL: http://sith.mimuw.edu.pl/~baggins/openldap/openldap-auditlog-modify.patch Submission from: (NULL) (2001:6a0:1:b001::2) In auditlog overlay the same variable is used to print what command and what modify operations are executed, resulting in somewhat mismatched logs. Example: # modify 1252272953 dn: dc=example,dc=com changetype: modify replace: contextCSN contextCSN: 20090828130628.442551Z#000000#001#000000 - # end replace 1252272953 ^^^^^^^^^^^^^^^^^ should read: # end modify 1252272953 I provided a patch to fix this at http://sith.mimuw.edu.pl/~baggins/openldap/openldap-auditlog-modify.patch

1 0

ITS#6285
by masarati＠aero.polimi.it 06 Sep '09

06 Sep '09

Please direct software interoperation questions to <openldap-technical(a)openldap.org>. This ITS will be closed. p.

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by hyc＠symas.com 05 Sep '09

05 Sep '09

ryans(a)aweber.com wrote: > Upon further review, it seems that the problem is $LIBTOOL not being defined. Should automake be setting this in > configure.in or Makefile.in ahead of time, The OpenLDAP Project does not use automake. > or is it up to each individual module to set the environment variables needed > for compiling/linking? -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

>> I think hitting an assert is always a bug, while exit(nonzero) is fine. >> Looks like a small fix anyway, if that's all there is to it. >> >> A quick grep found that back-ldap and back-meta also try to use the >> result message from ldap_result()==0. > > Unless I missed something, all times back-ldap and back-meta ignore > ldap_result()==0 it's because no timeout was specified. Actually, syncrepl is already requesting that objectClass, structuralObjectClass and entryCSN be present in the attrslist. I wonder whether entryUUID should be added. p.

1 0

Re: (ITS#6281) Duplicate entries when changing DN on newly created consumer
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

> UPDATE: this appears to be a case of user-error > > the ldapsearch was not pulling the entryUUID because of a malformed search > line. > The required syntax for the "attrs" (last part of line) should have been > '*' '+' > when making a dump. Omitting the '+' caused LDAP to regenerate the > entryUUIDs on the consumer, which would then subsequently mess up > syncing operations Perhaps slapd should at least warn when syncrepl is configured in a way that entryUUID and entryCSN are not replicated. p.

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

> I think hitting an assert is always a bug, while exit(nonzero) is fine. > Looks like a small fix anyway, if that's all there is to it. > > A quick grep found that back-ldap and back-meta also try to use the > result message from ldap_result()==0. Unless I missed something, all times back-ldap and back-meta ignore ldap_result()==0 it's because no timeout was specified. p.

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by quanah＠zimbra.com 05 Sep '09

05 Sep '09

--On Friday, September 04, 2009 7:15 PM +0000 ryans(a)aweber.com wrote: > Upon further review, it seems that the problem is $LIBTOOL not being > defined. Should automake be setting this in configure.in or Makefile.in > ahead of time, or is it up to each individual module to set the > environment variables needed for compiling/linking? For contrib modules, the variables must be defined by the user doing the compiling. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by ryans＠aweber.com 04 Sep '09

04 Sep '09

Upon further review, it seems that the problem is $LIBTOOL not being defined. Should automake be setting this in configure.in or Makefile.in ahead of time, or is it up to each individual module to set the environment variables needed for compiling/linking? -Ryan

1 0

(ITS#6284) New libtoolized autogroup Makefile broken
by ryans＠aweber.com 04 Sep '09

04 Sep '09

Full_Name: Ryan Steele Version: 2.4.17 OS: Ubuntu 8.04 LTD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The latest Makefile for autogroup in CVS HEAD (v1.2 of the Makefile), which was libtoolized by manu, is broken. See the following output of 'make': mode=link cc -version-info 0:0:0 \ -rpath /lib -module -o autogroup.la autogroup.lo gcc-4.2.real: 0:0:0: No such file or directory gcc-4.2.real: autogroup.lo: No such file or directory gcc-4.2.real: unrecognized option '-version-info' gcc-4.2.real: unrecognized option '-rpath' make: [autogroup.la] Error 1 (ignored) I believe it is because the rule for 'autogroup.la' incorrectly passes the options -version-info and -rpath to gcc. As an independent example of the same type of issue, consider this mailing list posting: http://sourceware.org/ml/automake/1999-04/msg00337.html - the issues are identical.

1 0

Re: (ITS#6281) Duplicate entries when changing DN on newly created consumer
by tjaviss＠gmail.com 04 Sep '09

04 Sep '09

UPDATE: this appears to be a case of user-error the ldapsearch was not pulling the entryUUID because of a malformed search line. The required syntax for the "attrs" (last part of line) should have been '*' '+' when making a dump. Omitting the '+' caused LDAP to regenerate the entryUUIDs on the consumer, which would then subsequently mess up syncing operations Please accept my apologies and close this entry - TJA

1 0

(ITS#6283) Missing $LDAP<option>s
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard env LDAP<option>=value ./ldapsearch ... does not work for these variables: $LDAPGSSAPI_ALLOW_REMOTE_PRINCIPAL (LDAP_OPT_X_GSSAPI_ALLOW_REMOTE_PRINCIPAL) $LDAPGSSAPI_ENCRYPT (LDAP_OPT_ENCRYPT) $LDAPGSSAPI_SIGN (LDAP_OPT_SIGN) $LDAPNETWORK_TIMEOUT (LDAP_OPT_NETWORK_TIMEOUT) $LDAPTIMEOUT (LDAP_OPT_TIMEOUT) $LDAPVERSION (LDAP_OPT_PROTOCOL_VERSION) because libldap/init.c:openldap_ldap_init_w_env() does not handle options with attrs[].type == <ATTR_GSSAPI, ATTR_OPT_TV,ATTR_OPT_INT>.

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

I think hitting an assert is always a bug, while exit(nonzero) is fine. Looks like a small fix anyway, if that's all there is to it. A quick grep found that back-ldap and back-meta also try to use the result message from ldap_result()==0. -- Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by hyc＠symas.com 04 Sep '09

04 Sep '09

Hallvard B Furuseth wrote: > Easily reproducable. Great, thanks. But there's nothing useful to fix here. If the ldap_result call doesn't return a result message, the only thing the client could do is exit(LDAP_LOCAL_ERROR) as the other failure cases do. I.e., because a connection has already been established, the library will not do any fallback. It only tries to fallback if the TCP connection attempt fails. I'm inclined to ignore this ITS since avoiding the assert() won't change the actual outcome of the command. > ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS="-O0 -g" > make -s > > echo TIMEOUT 1> ldaprc > > : Run a listening "server" which just sleeps > python -c 'import time; from socket import *; s = socket(AF_INET, SOCK_STREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(9999)'& > > gdb -q clients/tools/ldapsearch > (gdb) run -xh localhost:3890 > ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. > > (gdb) backtrace > #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 > #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 > #2 0x00002b81174866e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000413234 in ldap_parse_result (ld=0x65a7170, r=0x0, errcodep=0x7fffc814f1a8, matcheddnp=0x7fffc814f190, errmsgp=0x7fffc814f188, > referralsp=0x7fffc814f180, serverctrls=0x7fffc814f198, freeit=1) at error.c:255 > #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 > #5 0x0000000000403fef in main (argc=3, argv=0x7fffc8153508) at ldapsearch.c:912 > (gdb) frame 4 > #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 > 1422 rc = ldap_parse_result( ld, result,&err,&matched,&info,&refs, > (gdb) info locals > err = 0 > msgbuf = "\000\000\000\000\000\000\000\000\0005e\000\000\000\000\000(\000\000\000\021\000\000\000pqZ\006\000\000\000\000Àð\024Èÿ\177\000\000PpZ\006\000\000\000\000 rZ\006\000\000\000\000xqZ\006", '\0'<repeats 12 times>, "0óZ\006\000\000\000\000ðð\024Èÿ\177\000\000\025ú@", '\0'<repeats 13 times>, " ñ\024Èÿ\177\000\000pqZ\006\000\000\000\000\2008e\000\000\000\000\0000ñ\024Èÿ\177\000\000Qû@\000\000\000\000\0000ñ\024Èÿ\177\000\000`\216B\000\000\000\000\000PpZ\006\000\000\000\000ðñ\024Èÿ\177\000\000\003\000\000\000\000\000\000\000pqZ\006\000\000\000\000Pò\024Èÿ\177\000\000°\211@\000\000"... > info = 0x0 > refs = (char **) 0x0 > msgid = 1 > rc = 0 > result = (LDAPMessage *) 0x0 > ctrls = (LDAPControl **) 0x0 > matched = 0x0 > sctrlsp = (LDAPControl **) 0x0 > sctrls = {0x0, 0x65a7020, 0x443b26} > sctrl = {{ldctl_oid = 0xffffffff<Address 0xffffffff out of bounds>, ldctl_value = {bv_len = 0, bv_val = 0x0}, ldctl_iscritical = 0 '\0'}, { > ldctl_oid = 0x65a7050 "ldap://localhost:3890", ldctl_value = {bv_len = 106590352, bv_val = 0x4fc2<Address 0x4fc2 out of bounds>}, > ldctl_iscritical = -43 'Õ'}, {ldctl_oid = 0x65a7170 "0óZ\006", ldctl_value = {bv_len = 388262848, bv_val = 0x7fffc8153420 ""}, > ldctl_iscritical = -110 '\222'}} > nsctrls = 0 > __PRETTY_FUNCTION__ = "tool_bind" > -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Meh. Looks like ITS strips the quoted-printable header. Trying again, after editing away strings with 8-bit characters. BTW, this was a RE24 backtrace. Easily reproducable. ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS="-O0 -g" make -s echo TIMEOUT 1 > ldaprc : Run a listening "server" which just sleeps python -c 'import time; from socket import *; s = socket(AF_INET, SOCK_STREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(9999)' & gdb -q clients/tools/ldapsearch (gdb) run -xh localhost:3890 ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. (gdb) backtrace #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 #2 0x00002b81174866e6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000413234 in ldap_parse_result (ld=0x65a7170, r=0x0, errcodep=0x7fffc814f1a8, matcheddnp=0x7fffc814f190, errmsgp=0x7fffc814f188, referralsp=0x7fffc814f180, serverctrls=0x7fffc814f198, freeit=1) at error.c:255 #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 #5 0x0000000000403fef in main (argc=3, argv=0x7fffc8153508) at ldapsearch.c:912 (gdb) frame 4 #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 1422 rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, (gdb) info locals err = 0 msgbuf = ... info = 0x0 refs = (char **) 0x0 msgid = 1 rc = 0 result = (LDAPMessage *) 0x0 ctrls = (LDAPControl **) 0x0 matched = 0x0 sctrlsp = (LDAPControl **) 0x0 sctrls = {0x0, 0x65a7020, 0x443b26} sctrl = {{ldctl_oid = 0xffffffff <Address 0xffffffff out of bounds>, ldctl_value = {bv_len = 0, bv_val = 0x0}, ldctl_iscritical = 0 '\0'}, { ldctl_oid = 0x65a7050 "ldap://localhost:3890", ldctl_value = {bv_len = 106590352, bv_val = 0x4fc2 <Address 0x4fc2 out of bounds>}, ldctl_iscritical = -43}, {ldctl_oid = 0x65a7170, ldctl_value = {bv_len = 388262848, bv_val = 0x7fffc8153420 ""}, ldctl_iscritical = -110 '\222'}} nsctrls = 0 __PRETTY_FUNCTION__ = "tool_bind" -- Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Easily reproducable. ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS=3D= "-O0 -g" make -s echo TIMEOUT 1 > ldaprc : Run a listening "server" which just sleeps python -c 'import time; from socket import *; s =3D socket(AF=5FINET, S= OCK=5FSTREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(999= 9)' & gdb -q clients/tools/ldapsearch (gdb) run -xh localhost:3890 ldapsearch: error.c:255: ldap=5Fparse=5Fresult: Assertion `r !=3D ((voi= d *)0)' failed. (gdb) backtrace #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 #2 0x00002b81174866e6 in =5F=5Fassert=5Ffail () from /lib64/libc.so.6 #3 0x0000000000413234 in ldap=5Fparse=5Fresult (ld=3D0x65a7170, r=3D0x= 0, errcodep=3D0x7fffc814f1a8, matcheddnp=3D0x7fffc814f190, errmsgp=3D0x= 7fffc814f188,=20 referralsp=3D0x7fffc814f180, serverctrls=3D0x7fffc814f198, freeit=3D= 1) at error.c:255 #4 0x0000000000408cfd in tool=5Fbind (ld=3D0x65a7170) at common.c:1422= #5 0x0000000000403fef in main (argc=3D3, argv=3D0x7fffc8153508) at lda= psearch.c:912 (gdb) frame 4 #4 0x0000000000408cfd in tool=5Fbind (ld=3D0x65a7170) at common.c:1422= 1422 rc =3D ldap=5Fparse=5Fresult( ld, result, &err,= &matched, &info, &refs, (gdb) info locals err =3D 0 msgbuf =3D "\000\000\000\000\000\000\000\000\0005e\000\000\000\000\000(= \000\000\000\021\000\000\000pqZ\006\000\000\000\000=C0=F0\024=C8=FF\177= \000\000PpZ\006\000\000\000\000=A0rZ\006\000\000\000\000xqZ\006", '\0' = <repeats 12 times>, "0=F3Z\006\000\000\000\000=F0=F0\024=C8=FF\177\000\= 000\025=FA@", '\0' <repeats 13 times>, " =F1\024=C8=FF\177\000\000pqZ\0= 06\000\000\000\000\2008e\000\000\000\000\0000=F1\024=C8=FF\177\000\000Q= =FB@\000\000\000\000\0000=F1\024=C8=FF\177\000\000`\216B\000\000\000\00= 0\000PpZ\006\000\000\000\000=F0=F1\024=C8=FF\177\000\000\003\000\000\00= 0\000\000\000\000pqZ\006\000\000\000\000P=F2\024=C8=FF\177\000\000=B0\2= 11@\000\000"... info =3D 0x0 refs =3D (char **) 0x0 msgid =3D 1 rc =3D 0 result =3D (LDAPMessage *) 0x0 ctrls =3D (LDAPControl **) 0x0 matched =3D 0x0 sctrlsp =3D (LDAPControl **) 0x0 sctrls =3D {0x0, 0x65a7020, 0x443b26} sctrl =3D {{ldctl=5Foid =3D 0xffffffff <Address 0xffffffff out of bound= s>, ldctl=5Fvalue =3D {bv=5Flen =3D 0, bv=5Fval =3D 0x0}, ldctl=5Fiscri= tical =3D 0 '\0'}, { ldctl=5Foid =3D 0x65a7050 "ldap://localhost:3890", ldctl=5Fvalue =3D= {bv=5Flen =3D 106590352, bv=5Fval =3D 0x4fc2 <Address 0x4fc2 out of bo= unds>},=20 ldctl=5Fiscritical =3D -43 '=D5'}, {ldctl=5Foid =3D 0x65a7170 "0=F3= Z\006", ldctl=5Fvalue =3D {bv=5Flen =3D 388262848, bv=5Fval =3D 0x7fffc= 8153420 ""},=20 ldctl=5Fiscritical =3D -110 '\222'}} nsctrls =3D 0 =5F=5FPRETTY=5FFUNCTION=5F=5F =3D "tool=5Fbind" --=20 Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by Guillaume.Rousse＠inria.fr 04 Sep '09

04 Sep '09

Howard Chu a écrit : > Please provide the stack trace from this assert. Too late... Let's wait for next occurence of the problem. -- BOFH excuse #176: vapors from evaporating sticky-note adhesives

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by hyc＠symas.com 04 Sep '09

04 Sep '09

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.17 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > > With a frozen server, the following client configuration make ldapsearch fails > an assertion: > BASE dc=futurs,dc=inria,dc=fr > URI ldap://ldap.saclay.inria.fr ldap://ldap.lille.inria.fr > TLS_CACERTDIR /etc/pki/tls/rootcerts > TLS_REQCERT demand > NETWORK_TIMEOUT 2 > TIMEOUT 2 > TIMELIMIT 2 > > [rousse@stalingrad Desktop]$ ldapsearch -x > ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' > failed. > Abandon Please provide the stack trace from this assert. -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by Guillaume.Rousse＠inria.fr 04 Sep '09

04 Sep '09

Full_Name: Guillaume Rousse Version: 2.4.17 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) With a frozen server, the following client configuration make ldapsearch fails an assertion: BASE dc=futurs,dc=inria,dc=fr URI ldap://ldap.saclay.inria.fr ldap://ldap.lille.inria.fr TLS_CACERTDIR /etc/pki/tls/rootcerts TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2 [rousse@stalingrad Desktop]$ ldapsearch -x ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed. Abandon Such error prevent the client to fallback on second server. And a graceful exit would be more appropriate. A network capture of the client-server exchange is available at http://www.zarb.org/~guillomovitch/out

1 0

(ITS#6281) Duplicate entries when changing DN on newly created consumer
by tjaviss＠gmail.com 03 Sep '09

03 Sep '09

Full_Name: Tyler A Version: 2.4.11-1 OS: Debian/stable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.77.112.211) When a consumer is created from a clone of the master (slapd off, DB directory cleared. dumped to LDIF on master, LDIF imported on consumer, slapd started), a subsequent transaction that changes the DN of a entry will result in duplicate entries (1 with old DN and 1 with new DN). This might be related to the DB apparently missing the "entryUUID" field on entries, but these do not appear to be created despite the slapd config having "lastmod on"

1 0

(ITS#6280)
by Donald.Lewis＠Teradata.com 03 Sep '09

03 Sep '09

Howard, This is actaully about libldap_r, not libldap. Does that change anything? Regards, Jeff

1 0

Re: (ITS#6280) Race condition in TLS/SSL init code
by hyc＠symas.com 02 Sep '09

02 Sep '09

donald.lewis(a)teradata.com wrote: > Full_Name: Jeff Lewis > Version: 2.4.17 > OS: SuSE Linux, ES9& 10 > URL: > Submission from: (NULL) (153.65.16.10) > > > There appears to be a race condition in SSL/TLS setup in the LDAP client library > bind fucntions. We have workarounds for the problem in 2.3 and 2.4 which we > plan to use until we can get a proper fix so there is no time pressure on you > from my end. Since we have a viable workaround, we're happy leaving the choice > to address the issue or not to you. libldap is not documented to be thread-safe, nor is it intended to be. > 2. If, before the first bind attempt, I invoke ldap_set_option passing a NULL > LDAP pointer, LDAP_OPT_X_TLS_NEWCTX and a value of 0, I do not experience the > problem. We're quite happy with this as a workaround. This supports my belief > that the race is somewhere in the TLS initialization code. > > In 2.3.39 (our current OpenLDAP client), the problem is more severe. When > multiple threads collide in the TLS setup logic, the problem causes TLS to > become completely unusable and no connection can be established to the server. > We've repaired this problem in libraries/libldap/tls.c by calling > ldap_pvt_tls_init through pthread_once and we're quite happy to live with this > until we can get a 2.4 OpenLDAP imported. Your app is responsible for making sure that all libldap init functions are processed before multiple threads are created. Using pthread_once or whatever approach you take is up to you. Closing this ITS. -- -- 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#6280) Race condition in TLS/SSL init code
by Donald.Lewis＠Teradata.com 02 Sep '09

02 Sep '09

This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2C19.8E008473 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Forgot to say the the bind functions return -1 when the problem occurs. ------_=_NextPart_001_01CA2C19.8E008473 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>Re: (ITS#6280) Race condition in TLS/SSL init code</TITLE> </HEAD> <BODY>  <P><FONT SIZE=3D2 FACE=3D"Arial">Forgot to say the the bind functions = return -1 when the problem occurs.</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CA2C19.8E008473--

1 0

(ITS#6280) Race condition in TLS/SSL init code
by donald.lewis＠teradata.com 02 Sep '09

02 Sep '09

Full_Name: Jeff Lewis Version: 2.4.17 OS: SuSE Linux, ES9 & 10 URL: Submission from: (NULL) (153.65.16.10) There appears to be a race condition in SSL/TLS setup in the LDAP client library bind fucntions. We have workarounds for the problem in 2.3 and 2.4 which we plan to use until we can get a proper fix so there is no time pressure on you from my end. Since we have a viable workaround, we're happy leaving the choice to address the issue or not to you. In OpenLDAP release 2.4.17, there is a race condition of some sort when SSL or TLS is used. When two or more threads collide in the SSL/TLS setup code, one or both threads fail to connect. I believe this to be some sort of a one-time initialization problem because it is the first few bind attempts that seem to fail and once one bind succeeds, the rest seem to succeed. We observe this with simple binds using ldap_sasl_bind_s, ldap_simple_bind_s, or ldap_bind_s. We observe it on connections protected with SSL. We also observe it on connections protected with TLS. We do not observe any problems involving normal, unprotected LDAP connections. It would appear that SSL or TLS has to be in play. I've got two workarounds: 1. If I serialize the binds with a mutex, the problem disappears. This is not something we'd want to do in our product because of the large number of binds we have to do in a short period of time. 2. If, before the first bind attempt, I invoke ldap_set_option passing a NULL LDAP pointer, LDAP_OPT_X_TLS_NEWCTX and a value of 0, I do not experience the problem. We're quite happy with this as a workaround. This supports my belief that the race is somewhere in the TLS initialization code. In 2.3.39 (our current OpenLDAP client), the problem is more severe. When multiple threads collide in the TLS setup logic, the problem causes TLS to become completely unusable and no connection can be established to the server. We've repaired this problem in libraries/libldap/tls.c by calling ldap_pvt_tls_init through pthread_once and we're quite happy to live with this until we can get a 2.4 OpenLDAP imported.

1 0

Re: (ITS#6277) Missing documentation for cn=config
by gavin.henry＠gmail.com 02 Sep '09

02 Sep '09

Of course, but Ryan also mentioned the password policy overlay here and loading overlays in general via cn=config. On 01/09/2009, hyc(a)symas.com <hyc(a)symas.com> wrote: > ryans(a)aweber.com wrote: >> Gavin, >> >>> Well there are two places that talk about how to convert from slapd.conf >>> to cn=config formats. In the guide and man pages, so that is the best >>> way to do a full conversion and see the end result. >>> >>> Where would you like to see these added? >>> >>> Thanks for the feedback as always! >> >> My vote would be section 5.2.2.3 of the Admin Guide. Currently, it has 2 >> examples of loading modules consisting of >> libtool libraries, but I would think that it would be good to give an >> example which, for pedagogical purposes, explained >> how to instantiate an overlay in cn=config. For example, ppolicy and >> autogroup: > > autogroup is a contrib module. We only document usage of core features in > the > Admin Guide. > >> dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcPPolicyConfig >> olcOverlay: ppolicy > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6277) Missing documentation for cn=config
by hyc＠symas.com 01 Sep '09

01 Sep '09

ryans(a)aweber.com wrote: > Gavin, > >> Well there are two places that talk about how to convert from slapd.conf >> to cn=config formats. In the guide and man pages, so that is the best >> way to do a full conversion and see the end result. >> >> Where would you like to see these added? >> >> Thanks for the feedback as always! > > My vote would be section 5.2.2.3 of the Admin Guide. Currently, it has 2 examples of loading modules consisting of > libtool libraries, but I would think that it would be good to give an example which, for pedagogical purposes, explained > how to instantiate an overlay in cn=config. For example, ppolicy and autogroup: autogroup is a contrib module. We only document usage of core features in the Admin Guide. > dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcPPolicyConfig > olcOverlay: ppolicy -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs