- openldap-bugs - openldap.org

Re: (ITS#8459) security scans causing slapd failure
by michael＠stroeder.com 05 Jul '16

05 Jul '16

duffy.lasker(a)sykes.com wrote: > Full_Name: duffy lasker > Version: slapd version 2.4.40 > OS: CentOS 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (184.96.44.7) > > > security scans for kernel segmentation testing causes the slapd service to enter > failed state, whether the test is successful (causes segmentation fault) or > not. > > the ldap server is apparently flooded with STARTTLS events until test end or > successful fault caused. Note that the RHEL/CentOS packages of OpenLDAP are heavily patched and linked against libnss. Hence it's probably better to report this to them. Also there were some fixes in their packages recently. Did you yum update to latest package version? You can also try to reproduce this failure with recent OpenLDAP release built from source and linked to OpenSSL. That would be more important to the OpenLDAP community. Ciao, Michael.

1 0

(ITS#8459) security scans causing slapd failure
by duffy.lasker＠sykes.com 05 Jul '16

05 Jul '16

Full_Name: duffy lasker Version: slapd version 2.4.40 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (184.96.44.7) security scans for kernel segmentation testing causes the slapd service to enter failed state, whether the test is successful (causes segmentation fault) or not. the ldap server is apparently flooded with STARTTLS events until test end or successful fault caused. flooded event: ACCEPT from IP=xxx.xxx.xxx.xxx:yyyyyy (IP=0.0.0.0:389) slapd[1251]: conn=15765834 op=0 STARTTLS slapd[1251]: conn=15765834 op=0 RESULT oid= err=0 text= ACCEPT from IP=xxx.xxx.xxx.xxx:zzzzz (IP=0.0.0.0:6%6) slapd[1251]: conn=15765834 fd=35 closed (TLS negotiation failure) result: kernel: slapd[14239]: segfault at 10 ip 00007f5028f81c65 sp 00007f4ffdffa550 error 4 in libnss3.so[7f5028f3b000+11e000] systemd: slapd.service: main process exited, code=killed, status=11/SEGV systemd: Unit slapd.service entered failed state. systemd: slapd.service failed.

1 0

(ITS#8458) syncrepl ppolicy with LDIF backend fails
by mozo＠mozo.jp 01 Jul '16

01 Jul '16

Full_Name: Moriyoshi Koizumi Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.3.144.188) As LDIF backend tries to store the values for the attributes in "prettified" form and the value is transferred verbatim in wire, replication of pwdAttribute (1.3.6.1.4.1.42.2.27.8.1.1) ends up with the following error: > syncrepl_message_to_entry: rid=001 mo cheheck (pwdAttribute: value #0 invalid per syntax) The validation causing the error itself is done in the following part in servers/slapd/modify.c: /* * check that each value is valid per syntax * and pretty if appropriate */ for ( nvals = 0; !BER_BVISNULL( &ml->sml_values[nvals] ); nvals++ ) { struct berval pval; if ( pretty ) { rc = ordered_value_pretty( ad, &ml->sml_values[nvals], &pval, ctx ); } else { rc = ordered_value_validate( ad, &ml->sml_values[nvals], ml->sml_op ); } if( rc != 0 ) { snprintf( textbuf, textlen, "%s: value #%ld invalid per syntax", ml->sml_type.bv_val, (long) nvals ); *text = textbuf; return LDAP_INVALID_SYNTAX; } if( pretty ) { ber_memfree_x( ml->sml_values[nvals].bv_val, ctx ); ml->sml_values[nvals] = pval; } } where pwdAttribute has the corresponding prettifier assigned to its schema (servers/slapd/overlays/ppolicy.c), which eventually is fed with the value in prettified form that will effectively make slap_bv2ad() in attrPretty() fail. { Syntax *syn; MatchingRule *mr; syn = ch_malloc( sizeof( Syntax )); *syn = *ad_pwdAttribute->ad_type->sat_syntax; syn->ssyn_pretty = attrPretty; ad_pwdAttribute->ad_type->sat_syntax = syn; mr = ch_malloc( sizeof( MatchingRule )); *mr = *ad_pwdAttribute->ad_type->sat_equality; mr->smr_normalize = attrNormalize; ad_pwdAttribute->ad_type->sat_equality = mr; } The replication works fine for other such attributes that have the same syntax (OID, 1.3.6.1.4.1.1466.115.121.1.38) like objectClass because those attributes are accompanied by the validators as well as prettifiers which validate the value both in prettified and OID form. For instance, objectClass has the corresponding validator oialalidate() besides the prettifier objectClassPretty().

1 0

(ITS#8457) back-sql: unordered entries combined with pagination gives wrong results
by matthias.hunstock＠tu-ilmenau.de 28 Jun '16

28 Jun '16

Full_Name: Matthias Hunstock Version: git HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/fix-sql-order.patch Submission from: (NULL) (2001:638:904:bf:e544:e758:826b:80ce) Back-SQL does not use any "ORDER BY" statements when querying for ldap entries. If a client uses pagination, there is code that that generates an optimized SQL query with a WHERE clause like " AND ldap_entries.id > x " with x being the highest id from the last paginated search result. As the DBMS gives results in unsorted order, this leads to extremely reduced result sets because it is randomly cut off. The linked patch resolves the issue for us.

1 0

Re: (ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by lorenz＠cloudflare.com 28 Jun '16

28 Jun '16

--001a114aa6f8aae6bb0536563239 Content-Type: text/plain; charset=UTF-8 I did not know that! Thanks for your help. -- Lorenz --001a114aa6f8aae6bb0536563239 Content-Type: text/html; charset=UTF-8 <div dir="ltr">I did not know that! Thanks for your help.<div><br></div><div>--</div><div>Lorenz</div></div> --001a114aa6f8aae6bb0536563239--

1 0

(ITS#8456) slapacl segfaults with mdb if object does not exists
by best＠univention.de 28 Jun '16

28 Jun '16

Full_Name: Florian Best Version: 2.4.42+dfsg-2.210.201511060842 OS: UCS 4.1-2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.198.197.8) Running the following command causes a segfault. There is no object for the DN provided with "-b". gdb --args slapacl -D uid=Administator,cn=users,dc=school,dc=local -b uid=doesnotexists,dc=school,dc=local -d0 -u jejectClass:univentionAdminUserSettings Program received signal SIGSEGV, Segmentation fault. 0x00007ffff013fbc8 in mdb_txn_begin () from /usr/lib/ldap/back_mdb.so (gdb) bt #0 0x00007ffff013fbc8 in mdb_txn_begin () from /usr/lib/ldap/back_mdb.so #1 0x00007ffff3a3a8d0 in mdb_opinfo_get () from /usr/lib/ldap/back_mdb.so #2 0x00007ffff013aac6 in mdb_entry_get () from /usr/lib/ldap/back_mdb.so #3 0x0000000000498267 in overlay_entry_get_ov () #4 0x00000000004982e7 in ?? () #5 0x000000000043f236 in fe_acl_group %)%9 #6 0x000000000043cd28 in backend_group () #7 0x0000000000453d9c in slap_access_allowed () #8 0x00000000004980cd in ?? () #9 0x0000000000450d8c in access_allowed_mask () #10 0x000000000049f793 in slapacl () #11 0x00000000004160bf in main ()

1 0

Re: (ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by h.b.furuseth＠usit.uio.no 28 Jun '16

28 Jun '16

On 28. juni 2016 13:06, Lorenz Bauer wrote: > I had a look at your changes, it seems like they obsolete my other bug report > as well. Good, I'll close that. > At the same time, I think you are introducing a double free? In copyfd1, if > memalign (and friends) fails you goto done, which then proceeds to free(). > Same for the case where CreateMutex or CreateFree return an error, since they > happen before allocation, but also goto done. In those cases the code leaves the HANDLE or pointer = NULL. free(NULL) does nothing. The "done:" code omits CloseHandle when the handle is NULL. Hmm. Unless failed posix_memalign() may put garbage in the destination pointer. Probably not, but can tweak the code to be safe just in case. -- Hallvard

1 0

Re: (ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by lorenz＠cloudflare.com 28 Jun '16

28 Jun '16

--94eb2c033d26fe88ce053654a1b2 Content-Type: text/plain; charset=UTF-8 I had a look at your changes, it seems like they obsolete my other bug report as well. At the same time, I think you are introducing a double free? In copyfd1, if memalign (and friends) fails you goto done, which then proceeds to free(). Same for the case where CreateMutex or CreateFree return an error, since they happen before allocation, but also goto done. -- Lorenz On 28 June 2016 at 11:09, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no > wrote: > Looks like a dup of ITS#8209. I've pushed a fix to > mdb.master. Hadn't gotten around to testing it properly. > > -- > Hallvard > --94eb2c033d26fe88ce053654a1b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I had a look at your changes, it seems like they obsolete = my other bug report as well.<div><br></div><div>At the same time, I think y= ou are introducing a double free? In copyfd1, if memalign (and friends) fai= ls you goto done, which then proceeds to free(). Same for the case where Cr= eateMutex or CreateFree return an error, since they happen before allocatio= n, but also goto done.</div><div><br></div><div>--</div><div>Lorenz</div></= div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 28 June 20= 16 at 11:09, Hallvard Breien Furuseth <span dir=3D"ltr"><<a href=3D"mail= to:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.uio.no</a>= ></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks like a dup of IT= S#8209.=C2=A0 I've pushed a fix to<br> mdb.master.=C2=A0 Hadn't gotten around to testing it properly.<span cla= ss=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> Hallvard<br> </font></span></blockquote></div><br></div> --94eb2c033d26fe88ce053654a1b2--

1 0

Re: (ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by lorenz＠cloudflare.com 28 Jun '16

28 Jun '16

--001a1143e19852a7140536547685 Content-Type: text/plain; charset=UTF-8 Thanks for the fix, and my bad for not finding the bug report. I didn't use the ITS interface properly. -- Lorenz On 28 June 2016 at 11:09, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no > wrote: > Looks like a dup of ITS#8209. I've pushed a fix to > mdb.master. Hadn't gotten around to testing it properly. > > -- > Hallvard > --001a1143e19852a7140536547685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for the fix, and my bad for not finding the bug rep= ort. I didn't use the ITS interface properly.<div><br></div><div>--</di= v><div>Lorenz<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On 28 June 2016 at 11:09, Hallvard Breien Furuseth <span dir=3D"ltr"><<a= href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth@us= it.uio.no</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks li= ke a dup of ITS#8209.=C2=A0 I've pushed a fix to<br> mdb.master.=C2=A0 Hadn't gotten around to testing it properly.<span cla= ss=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> Hallvard<br> </font></span></blockquote></div><br></div></div></div> --001a1143e19852a7140536547685--

1 0

Re: (ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by h.b.furuseth＠usit.uio.no 28 Jun '16

28 Jun '16

Looks like a dup of ITS#8209. I've pushed a fix to mdb.master. Hadn't gotten around to testing it properly. -- Hallvard

1 0

(ITS#8455) LMDB: mdb_env_copyfd1 leaks memory and pthread state if mdb_txn_begin fails
by lmb＠cloudflare.com 28 Jun '16

28 Jun '16

Full_Name: Lorenz Bauer Version: git c367c1f69685 OS: OS X URL: https://gist.github.com/lmb/c48dcdb74b4bc9bf4ecae1d70553d623 Submission from: (NULL) (2a06:98c0:1000:1200:1160:b579:2042:d902) In case that mdb_txn_begin fails (e.g. due to no more reader slots available), mdb_env_copyfd1 leaks my.mc_wbuf[0]. From the pthread_create man pages, it seems like it also leaks pthread state, since the created thread is never joined. The linked gist contains a test case, valgrind output which confirms that the buffer is leaked, and a patch. The patch properly frees the buffer, and always joins the thread. If the thread was never created pthread_join simply returns an error, which is ignored anyways. I think the same logic holds on Windows.

1 0

(ITS#8454) audit-log overlay man pag needs some improvement
by elecharny＠apache.org 28 Jun '16

28 Jun '16

Full_Name: Emmanuel Lecharny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.235.65.101) The current slapo-auditlog could be improve a bit by providing some more context about the audit log file content. Typically, the first like contains important informations like : - the operation - the timestamp - the database suffix - the modifiers' name - and the connection ID When this connection ID is -1, it would be interesting in the man page to inform the users that this update is an internal update (ie, something caused by an internal slapd update, not an user update). A simple sentence could be : "A 'conn=-1' in the first line tells that this is an internal operation, not an user initiated operation".

1 0

Re: (ITS#8453) lmdb: fix warning on Apple platforms
by catwell＠archlinux.us 27 Jun '16

27 Jun '16

Actually, ignore this: it's the same as 8407 which you closed as wontfix.= =0A=0ASorry for the noise.=0A=0A-- =0APierre Chapuis

1 0

(ITS#8453) lmdb: fix warning on Apple platforms
by catwell＠archlinux.us 27 Jun '16

27 Jun '16

Full_Name: Pierre Chapuis Version: OS: macOS / iOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.79.254.46) Apple compilers (and probably others) do not allow calling sprintf with fewer arguments than the format calls for. The warning is: mdb.c:10720:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ Proposed patch against current LMDB sterer: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 79a958b..84afe4f 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -10715,9 +10715,13 @@ mdb_reader_list(MDB_env *env, MDB_msg_func *func, void *ctx) for (i=0; i<rdrs; i++) { if (mr[i].mr_pid) { txnid_t txnid = mr[i].mr_txnid; - sprintf(buf, txnid == (txnid_t)-1 ? - "%10d %"Z"x -\n" : "%10d %"Z"x %"Y"u\n", - (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); + if (txnid == (txnid_t)-1) { + sprintf(buf, "%10d %"Z"x -\n", + (int)mr[i].mr_pid, (size_t)mr[i].mr_tid); + } else { + sprintf(buf, "%10d %"Z"x %"Z"u\n", + (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); + } if (first) { first = 0; rc = func(" pid thread txnid\n", ctx);

1 0

(ITS#8452) LMDB: mdb_env_copyfd2 can deadlock due to missing mdb_env_cthr_toggle check
by lmb＠cloudflare.com 27 Jun '16

27 Jun '16

Full_Name: Lorenz Bauer Version: git c367c1f69685 OS: OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a06:98c0:1000:1200:156f:df88:ee9a:7775) The function mdb_env_copyfd2 with MDB_CP_COMPACT enabled can currently deadlock, since a call to mdb_env_cthr_toggle is not checked. The testcase at https://gist.github.com/lmb/17a528cdadde73fb231a2a1ed84714f7 reproduces this issue as follows: - Use pthread_sigmask to ignore SIGPIPE - Create new pipe - Spawn thread with mdb_env_copyfd2 using MDB_CP_COMPACT - Close read side of the pipe in main thread - Join thread and check rc code On LMDB master the testase e hangs instead of returning EPIPE. The following patch fixes the deadlock, but since I'm not very familiar with the codebase it's likely incorrect. diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 79a958b..97ff7c7 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -9988,11 +9988,15 @@ mdb_env_copyfd1(MDB_env *env, HANDLE fd) rc = mdb_env_cwalk(&my, &txn->mt_dbs[MAIN_DBI].md_root, 0); if (rc == MDB_SUCCESS && my.mc_wlen[my.mc_toggle]) rc = mdb_env_cthr_toggle(&my, 1); - mdb_env_cthr_toggle(&my, -1); + rc = mdb_env_cthr_toggle(&my, -1); + if (rc) + goto done; pthread_mutex_lock(&my.mc_mutex); while(my.mc_new) pthread_cond_wait(&my.mc_cond, &my.mc_mutex); pthread_mutex_uocock(&my.mc_mutex); + +done: THREAD_FINISH(thr); mdb_txn_abort(txn);

1 0

Re: (ITS#8450) race condition in ldap_int_utils_init
by hyc＠symas.com 27 Jun '16

27 Jun '16

doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: 2.4.44 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.254.4.13) > > > There is a race condition in ldap_int_utils_init that can be triggered when > multiple threads enter ldap_int_utils_init from ldap_init_initialize about the > same time. The done flag gets set immediately, before the various mutexes are > initialized. If thread A sets done, and thread B tests for done==1 before thread > A has completed the mutex inits, thread B can attempt to use an uninitialized > mutex and fail/core dump etc. > > Additionally if judt the done=1 is moved to the bottom of the function thwo > threads can both be initializing the same mutexes multiple times causes other > mayhem. > > The short term workaround for Solaris (THR APIs) is to move setting of done=1 to > after the mutex inits, and to protect the mutex inits using another statically > initialized mutex within ldap_int_utils_init. > I know a similar workaround could be made for POSIX threads and possibly some of > the other supported thread models, but this approach seems kludgely. Static initializers would be the simplest fix, certainly. On Windows we'd have to use something similar to pthread_once() for initialization, instead. > I suspect the correct solution may be to somehow refactor ldap_int_utils_init > out of libldap and into libldap_r in a cleaner multi-platform manner than the > example above. > > -- -- 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#8099) Documentation bug with 'tls_cipher(_)suite' option
by ryan＠nardis.ca 25 Jun '16

25 Jun '16

Thanks for that. Fixed in git master.

1 0

Re: (ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by nightdragon＠gmx.at 25 Jun '16

25 Jun '16

The bug also exists in your doc (http://www.openldap.org/doc/admin24/guide.html) at chapter "5.2.5.8. olcSyncrepl" and "6.2.3.7. syncrepl"

1 0

Re: (ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by nightdragon＠gmx.at 25 Jun '16

25 Jun '16

This is a multipart message in MIME format. ------=_NextPart_000_0067_01D1CE86.D61EFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit your doc (http://www.openldap.org/doc/admin24/guide.html) at chapter "5.2.5.8. olcSyncrepl" and "6.2.3.7. syncrepl" ------=_NextPart_000_0067_01D1CE86.D61EFE70 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 15 = (filtered medium)"><style></style></head><body lang=3DDE-AT = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p = class=3DMsoNormal><span lang=3DEN-US>your doc (<a = href=3D"http://www.openldap.org/doc/admin24/guide.html">http://www.openld= ap.org/doc/admin24/guide.html</a>) at chapter „5.2.5.8. = olcSyncrepl“ and „6.2.3.7. = syncrepl“<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p></div></body></html> ------=_NextPart_000_0067_01D1CE86.D61EFE70--

1 0

(ITS#8450) race condition in ldap_int_utils_init
by doug.leavitt＠oracle.com 24 Jun '16

24 Jun '16

Full_Name: Doug Leavitt Version: 2.4.44 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.254.4.13) There is a race condition in ldap_int_utils_init that can be triggered when multiple threads enter ldap_int_utils_init from ldap_init_initialize about the same time. The done flag gets set immediately, before the various mutexes are initialized. If thread A sets done, and thread B tests for done==1 before thread A has completed the mutex inits, thread B can attempt to use an uninitialized mutex and fail/core dump etc. Additionally if judt the done=1 is moved to the bottom of the function thwo threads can both be initializing the same mutexes multiple times causes other mayhem. The short term workaround for Solaris (THR APIs) is to move setting of done=1 to after the mutex inits, and to protect the mutex inits using another statically initialized mutex within ldap_int_utils_init. Example patch: -- util-int.c.~1~ 2016-02-05 17:57:45.000000000 -0600 +++ util-int.c 2016-06-24 13:20:09.793308570 -0500 @@ -89,12 +89,16 @@ # endif # if defined(HAVE_GETHOSTBYADDR_R) && \ (GETHOSTBDDDDR_R_NARGS < 7) || (8 < GETHOSTBYADDR_R_NARGS) /* Don't know how to handle this version, pretend it's not there */ # undef HAVE_GETHOSTBYADDR_R # endif +#if defined( HAVE_THR ) + /* use static mutex to protect mutex initialization */ +static mutex_t ldap_int_utils_init_mutex = DEFAULTMUTEX; +#endif /* HAVE_THR */ #endif /* LDAP_R_COMPILE */ char *ldap_pvt_ctime( const time_t *tp, char *buf ) { #ifdef USE_CTIME_R # if (CTIME_R_NARGS > 3) || (CTIME_R_NARGS < 2) @@69697,15 +701,22 @@ void ldap_int_utils_init( void ) { static int done=0; if (done) return; - done=1; #ifdef LDAP_R_COMPILE +#if defined( HAVE_THR ) + /* use static mutex to protect mutex initialization */ + (void) mutex_lock(&ldap_int_utils_init_mutex); + if (done) { + (void) mutex_unlock(&ldap_int_utils_init_mutex); + return; + } +#endif /* HAVE_THR */ #if !defined( USE_CTIME_R ) && !defined( HAVE_REENTRANT_FUNCTIONS ) ldap_pvt_thread_mutex_init( &ldap_int_ctime_mutex ); #endif #if !defined( USE_GMTIME_R ) && !defined( USE_LOCALTIME_R ) ldap_pvt_thread_mutex_init( &ldap_int_gmtime_mutex ); #endif @@ -715,15 +726,20 @@ ldap_pvt_thread_mutex_init( &ldap_int_gettime_mutex ); #ifdef HAVE_GSSAPI ldap_pvt_thread_mutex_init( &ldap_int_gssapi_mutex ); #endif -#endif /* call other module init functions here... */ + done=1; +#if defined( HAVE_THR ) + /* use static mutex to protect mutex initialization */ + (void) mutex_unlock(&ldap_int_utils_init_mutex); +#endif /* HAVE_THR */ +#endif } #if defined( NEED_COPY_HOSTENT ) # undef NEED_SAFE_REALLOC #define NEED_SAFE_REALLOC I know a similar workaround could be made for POSIX threads and possibly some of the other supported thread models, but this approach seems kludgely. I suspect the correct solution may be to somehow refactor ldap_int_utils_init out of libldap and into libldap_r in a cleaner multi-platform manner than the example above.

1 0

Re: (ITS#8449) slapadd - config file
by quanah＠openldap.org 23 Jun '16

23 Jun '16

--On Thursday, June 23, 2016 10:24 AM +0000 s.gopinath(a)nic.in wrote: > Full_Name: SGopinath > Version: 2.4.44 > OS: Debian 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (164.100.167.137) > > > Dear Sir, > > I follow the steps provided in the Admin guide and doing source > installation. > > It compiles well and make install is okay. > > After that when I give > > usr/local/sbin/slapadd -F /usr/local/etc/config=cn -l > /r%r/local/etc/openldap/slapd.ldif > > It says... > 576baa27 invalid config directory /usr/local/etc/config=cn, error 2 > slapadd: bad configuration directory! Use /usr/local/etc/slapd.d. This is a typo that will be fixed with the next release. Generally the ITS system is for reporting bugs, not asking usage questions. In the future, please use openldap-technical(a)openldap.org for these types of questions. --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

(ITS#8449) slapadd - config file
by s.gopinath＠nic.in 23 Jun '16

23 Jun '16

Full_Name: SGopinath Version: 2.4.44 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.100.167.137) Dear Sir, I follow the steps provided in the Admin guide and doing source installation. It compiles well and make install is okay. After that when I give usr/local/sbin/slapadd -F /usr/local/etc/config=cn -l /r%r/local/etc/openldap/slapd.ldif It says... 576baa27 invalid config directory /usr/local/etc/config=cn, error 2 slapadd: bad configuration directory! Please help. Thanks, S.Gopinath

1 0

Re: (ITS#8447) LMDB: Overwriting values in MDB_DUPSORT databases broken
by h.b.furuseth＠usit.uio.no 22 Jun '16

22 Jun '16

On 21. juni 2016 01:35, hyc(a)symas.com wrote: > This is a misuse of MDB_CURRENT: as documented, the new value is supposed to > be the same size as the existing value. No, that's not what the doc says. "MDB_CURRENT - (...) intended to be used when the new data is the same size as the old. Otherwise it will simply perform a delete of the old record followed by an insert." I think LMDB should check the size, even if you change the doc to match the code rather than the other way around. If you want to avoid error checks, I'd rather avoid EINVAL checks like key==NULL which are easier for the user to check than "old size = new size". -- Hallvard

1 0

(ITS#8448) slapd aborted during replication
by quanah＠openldap.org 21 Jun '16

21 Jun '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44+ITS8432 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) No symbol table info available. #4 0x00000000004ae6ba in slap_sl_malloc (size=140240355863183, ctx=0x0) at sl_malloc.c:310 sh = 0x0 ptr = 0xf4240 newptr = 0x0 __PRETTY_FUNCTION__ = "slap_sl_malloc" #5 0x00000000004582a2 in build_new_dn (new_dn=0x2190050, parent_dn=0x249b6c0, newrdn=0x7f8c3df35100, memctx=0x0) at dn.c:1154 ptr = 0x1640da00 "cn=accesslog" #6 0x00007f949e4f5bf1 in accesslog_entry (op=0x7f8c3df363f0, rs=0x7f8c3df35f70, logop=2, op2=0x7f8c3df352a0) at accesslog.c:1325 on = 0x22221e0 li = 0x2207de0 rdnbuf = "reqStart=20160620160747.1000000\000$R\363=\214\177" nrdnbuf = "reqStart=\000\266\236\224\177\000\000\000\000\000\000\000\000\000\000lR\363=\214\177\000\000\000 \230@\214\177" rdn = {bv_len = 31, bv_val = 0x7f8c3df35150 "reqStart=20160620160747.1000000"} nrdn = {bv_len = 140240355863169, bv_val = 0x7f8c3df35120 "reqStart="} timestamp = {bv_len = 22, bv_val = 0x7f8c3df35159 "20160620160747.1000000"} ntimestamp = {bv_len = 140240355863160, bv_val = 0x245a000 ""} bv = {bv_len = 140240311506032, bv_val = 0x7f8c3df35250 ""} lo = 0x7f949e6fcb10 e = 0x2190038 #7 0x00007f949e4f6614 in accesslog_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at accesslog.c:1528 on = 0x22221e0 li = 0x2207de0 a = 0x7f8c4098b010 last_attr = 0x8 m = 0x7f8c3df35488 b = 0x7f8c40958ff8 uuid = {bv_len = 36, bv_val = 0x10209c00 "28031e5e-38fb-1033-9eea-e5803fce8315"} i = 0 logop = 2 do_graduate = 0 lo = 0x7f949e6fcb10 e = 0x0 old = 0x0 e_uuid = 0x0 timebuf = "\300\340H\004\000\000\000\000\000\240E\002\000\000\000\000\240T\363=\214\177\000\000xf\267\000\000" bv = {bv_len = 64424509440, bv_val = 0x7f8c3df35520 "p_\363=\214\177"} ptr = 0x245a088 "" vals = 0x448e000 op2 = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = { rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = { bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} rs2 = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} #8 0x00000000004cd9b6 in over_back_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at backover.c:237 oi = 0x2222b40 on = 0x22221e0 rc = 32768 be = 0x7f8c3df35c30 db = {bd_info = 0x22221e0, bd_self = 0x20598e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", 'C5C000' <repeats 14 times>, "\001", be_flags = 563464, 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 = 0x249c500, be_nsuffix = 0x249c540, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x23bb960, 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 = 0x3e86060, 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 = 0x21b18c0, be_pb = 0x0, be_cf_ocs = 0x7f949ed7e120, be_private = 0x2772000, be_next = {stqe_next = 0x0}} #9 0x0000000000450522 in slap_response_play (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:537 sc_next = 0x7f8c3df35fe0 sc_nextp = 0x7f8c3df35c00 rc = 32768 sc = 0x5c680a8 scp = 0x5c680a8 #10 0x0000000000450747 in send_ldap_response (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:612 berbuf = { buffer = "\000\000\000\000\000\000\000\000\260\201\306\005\000\000\000\000\200Y\363=\214\177\000\000\360c\363=\214\177\000\000\n", '\000' <repeats 15 times>, "@\312\344\001\000\000\000\000\060\\\363=\214\177", '\000' <repeats 18 times>, "@X\363=\214\177\000\000\326P\264\236\224\177\000\000\252\004\230@\214\177\000\000\205\243\265\236\224\177\000\000\240X\363=\214\177\000\000\200X\363=\214\177\000\000\200Y\363=\214\177\000\000\360c\363=\214\177\000\000\000 w\002\000\000\000\000\000 w\002\000\000\000\000\005\000\000\000\000\000\000\000p\002", '\000' <repeats 14 times>"\323, \004\230@\214\177\000\000\f\003\230@\214\177\000\000\000\240E\002\000\000\000\000pX\363=\214\177\000\000\200\214\363?\214\177\000\000\300y\363=\214\177\000\000i\267W\242\224\177", '\000' <repeats 17 times>, ialign = 0, lalign = 0, falign = 0, dalign = 0, palign = 0x0} ber = 0x7f8c3df35770 rc = 0 bytes = 274615488 __PRETTY_FUNCTION__ = "send_ldap_response" #11 0x0000000000451691 in slap_send_ldap_result (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at result.c:891 tmp = 0x0 otext = 0x0 o oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #12 0x00007f949eb47abe in mdb_modify (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at modify.c:708 mdb = 0x2772000 e = 0x5c68160 manageDSAit = 2 textbuf = "\017\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\250\200\306\005\000\000\000\000\371\377\377\377\377\377\377\377\240Z\363=\214\177\000\000\200\214\363?\214\177\000\000\300y\363=\214\177\000\000\004\000\000\000\000\000\000\000\a\000\000\000\000\000\000\000%\rM\000\000\000\000\000\240Z\363=\214\177\000\000\070e\363=\214\177\000\000\003\000\000\000\000\000\000\000^\200\306\005\000\000\000\000Ѐ\306\005\000\000\000\000a\200\306\005\000\000\000\000^\200\306\005\000\000\000\000\001\000\000\000\001\000\000\000\250\200\306\005\000\000\000\000p_\363=\214\177\000\000p[\363=\214\177\000\000\371np\236\224\177\000\000p_\363=\214\177\000\000\360c\363=\214\177\000\000Ѐ\306\005\000\000\000\000\360c\363=\214\177\000\000Ȃ\306\005\000\000\000\000(d\363=\214\177\000\000p[\363=\214\177\000\000\374\200O\236\224\177\000\000p_\363=\214\177\000\000\360c\363=\214\177\000" textlen = 256 txn = 0x0 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, moi_txn = 0x245a000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f8c3df359e0 dummy = {e_id = 0, e_name = {bv_len = 0, bv_val = 0xf8d2e98 ""}, e_nname = {bv_len = 0, bv_val = 0x5c68540 ""}, e_attrs = 0x975dfa0, e_ocflags = 82208, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x5c68160} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x39e66a4fee, 0x7f8c3df35f70, 0x7f8c3df363f0, 0x7f8c3df35a45, 0x0} num_ctrls = 0 numads = 1324 #13 0x00000000004ce903 in overlay_op_walk (op=0x7f8c3df363f0, rs=0x7f8c3df35f70, which=op_modify, oi=0x2222b40, on=0x0) at backover.c:677 func = 0x7f949ed7e418 rc = 32768 #14 0x00000000004ceb30 in over_op_func (op=0x7f8c3df363f0, rs=0x7f8c3df35f70% w which=op_modify) at backover.c:730 oi = 0x2222b40 on = 0x2222960 be = 0x20598e0 db = {bd_info = 0x7f949ed7e3c0, bd_self = 0x20598e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\101\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, 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 = 0x249c500, be_nsuffix = 0x249c540, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x23bb960, 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 = 0x3e86060, 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 = 0x21b18c0, be_pb = 0x0, be_cf_ocs = 0x7f949ed7e120, be_private = 0x2772000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f8c3df35fe0, sc_response = 0x4cd8da <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x2222b40} sc = 0xfb532c0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #15 0x00000000004cec6c in over_op_modify (op=0x7f8c3df363f0, rs=0x7f8c3df35f70) at backover.c:769 No locals. #16 0x00000000004c157e in syncrepl_updateCookie (si=0x21b2ec0, op=0x7f8c3df363f0, syncCookie=0x7f8c3df36230) at syncrepl.c:3434 be = 0x20598e0 mod = {sml_mod = {sm_desc = 0x1e4ca40, sm_values = 0xf7686c0, sm_nvalues = 0x0, sm_numvals = 5, sm_op = 2, sm_flags = 1, sm_type = {bv_len = 10, bv_val = 0x1e35340 "contextCSN"}}, sml_next = 0x0}% first = {bv_len = 40, bv_val = 0x164ac690 "20160620160747.996249Z#000000#001#000000"} sc = {ctxcsn = 0xf7686c0, sids = 0x126ee0e0, numcsns = 5, rid = 0, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 0, sc_next = {stqe_next = 0x0}} syn = 0x20359e0 rc = 0 i = 1 j = 1 changed = 1 len = 40 cb = {sc_next = 0x5c68078, sc_response = 0x4c3068 <null_callback>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x21b2ec0} rs_modify = {sr_type = REP_RESULT, sr_tag = 103, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} __PRETTY_FUNCTION__ = "syncrepl_updateCookie" #17 0x00000000004b6f98 in do_syncrep2 (op=0x7f8c3df363f0, si=0x21b2ec0) at syncrepl.c:1017 match = 4443238 syncUUID = {{bv_len = 16, bv_val = 0x14772a87 "\340\061\242\332\313L\020\065\223\323S`\265\303zY"}, {bv_len = 18446744073709551615, bv_val = 0x7f8c3df36660 ""}} cookie = {bv_len = 60, bv_val = 0x14772a99 "rid=100,sid=001,csn=20160620160747.996249Z#000000#001#000000"} rctrls = 0xd97f0a0 rctrlp = 0x12070920 bdn = {bv_len = 44, bv_val = 0xf99c40a "reqStart=20160620160747.996073Z,cn=accesslog"} si_tag = 140240311511856 entntry = 0x39e698d440 punlock = 0 syncstate = 1 retdata = 0x10000 retoid = 0x0 syncUUIDs = 0xa000009af len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>"\200, *w\024\000\000\000\000\325*w\024\000\000\000\000\325*w\024", '\000' <repeats 28 times>, " c\363=\214\177\000\000\000\000\000\000\000\000\000\000\360b\363=\214\177\000\000\274\370\037S\377\177\000\000\360c\363=\214\177\000\000\226Zy\242\224\177\000\000\060c\363=\214\177\000\000\000\232u\000\000\000\000\000\060c\363=\214\177\000\000\341YE\000\000\000\000\000\bd\363=\214\177\000\000\000d\363=\214\177\000\000\323\024hW\000\000\000\000\226Zy\242\224\177\000\000\200c\363=\214\177\000\000Ⱥ\332\n\000\000\000\000\300c\363=\214\177\000\000\366\254{\242\224\177\000\000\360c\363=\214\177\000\000\354c\363=\214\177\000\000\220c\363=\001\000\000\000@\200\261\n\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7f8c3df36270 msg = 0x12930680 syncCookie = {ctxcsn = 0x129f7660, sids = 0x1383c138, numcsns = 1, rid = 100, octet_str = {bv_len = 60, bv_val = 0x12551a80 "rid=100,sid=001,csn=20160620160747.996249Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x14146ae0, sids = 0x12c7ca00, numcsns = 5, rid = 100, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 3, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 32652 tout_p = 0x7f8c3df361c0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #18 0x00000000004b9107 in do_syncrepl (ctx=0x7f8c3df36b30, arg=0x1e3ddb0) at syncrepl.c:1565 rtask = 0x1e3ddb0 si = 0x21b2ec0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_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}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f30b0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f30b0 ""}, c_listener = 0x4fb160, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_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}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_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}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x45127c <slap_send_ldap_result>, c_send_search_entry = 0x452160 <slap_send_search_entry>, c_send_search_reference = 0x454210 <slap_send_search_reference>, c_send_ldap_extended = 0x451c22 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x451f3d <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f8c3df36560, o_tag = 102, o_time = 1466438867, o_tincr = 1000000, o_bd = 0x7f8c3df35530, o_req_dn = {bv_len = 0, bv_val = 0x1e2d050 ""}, o_req_ndn = { bv_len =%2, bv_val = 0x1e2d050 ""}, o_request = {oq_add = {rs_modlist = 0x7f8c3df36060, rs_e = 0x1}, oq_bind = {rb_method = 1039360096, rb_cred = {bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = Bbv_v_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f8c3df36060}, oq_modify = {rs_mods = { rs_modlist = 0x7f8c3df36060, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f8c3df36060, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 1039360096, rs_deref = 32652, rs_slitit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 1039360096}, oq_cancel = {rs_msgid = 1039360096}, oq_extended = {rs_reqoid % % {bv_len = 140240311509088, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 140240311509088, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 time3E3E, o_controls = 0x7f8c3df366a8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x25409c0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x25409e0 "cn=config"}, sai_ssf =%2, sai_tranorort_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f8c3df35c00, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x5c68040 "20160620160747.996249Z#000000#001#000000"}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 100, oh_conn = 0x7f8c3df367b0, oh_msgid = 0, oh_protocol = 0, oh_tid = 140240311514880, oh_threadctx = 0x7f8c3df36b30, oh_tmpmemctx = 0x44ad780, oh_tmpmfuncs = 0x757a40, oh_counters = 0x75af80, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 17 times>, 0x7f8c3df36230, 0x0 <repeats 14 times>}} op = 0x7f8c3df363f0 rc = 0 dostop = 0 s = 113 i = 0 defer = 1 fail = 0 freeinfo = 0 be = 0x20598e0 #19 0x000000000043adb9 in connection_read_thread (ctx=0x7f8c3df36b30, argv=0x71) at connection.c:1273 rc = 0 cri = {op = 0x0, func = 0x4b8bdf <do_syncrepl>, arg = 0x1e3ddb0, ctx = 0x7f8c3df36b30, nullop = 0} s = 113 #20 0x00007f94a2794332 in ldap_int_thread_pool_wrapper (xpool=0x1e64000) at tpool.c:956 pq = 0x1e64000 pool = 0x2028240 task = 0x44ab020 work_list = 0x1e64070 ctx = {ltu_pq = 0x1e64000, ltu_id = 140240311514880, ltu_key = {{ltk_key = 0x43a347, ltk_data = 0x2033b00, ltk_free = 0x43a18b <conn_counter_destroy>}, {ltk_key = 0x4ae1c7, ltk_data = 0x44ad780, ltk_free = 0x4adfec <slap_sl_mem_destroy>}, {ltk_key = 0x4555e5, ltk_data = 0x14317680, ltk_free = 0x455538 <slap_op_q_destroy>}, {ltk_key = 0x2030d00, ltk_data = 0x47c8800, ltk_free = 0x7f949eb59723 <mdb_reader_free>}, {ltk_key = 0x7f949eb4e554, ltk_data = 0x745a000, ltk_free = 0x7f949eb4e531 <search_stack_free>}, { ltk_key = 0x7f949eb4b011, ltk_data = 0x715a000, ltk_free = 0x7f949eb4afc9 <scope_chunk_free>}, {ltk_key = 0x2031400, ltk_data = 0x5e09400, ltk_free = 0x7f949eb59723 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x12f37200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 786 hash = 3996113682 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #21 0x00000039e6a079d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #22 0x00000039e66e88fd in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8445) LibreSSL v2.4 compile
by cpaynetaffe＠gmail.com 21 Jun '16

21 Jun '16

--001a113faca2cd5c170535ccd806 Content-Type: text/plain; charset=UTF-8 This is LibreSSL's response. ---------- Forwarded message --------- From: Bob Beck <beck(a)obtuse.com> Date: Tue, Jun 21, 2016 at 11:45 AM Subject: Re: OpenSSL v1.1 API To: Connor Taffe <cpaynetaffe(a)gmail.com> Cc: <libressl(a)openbsd.org> I would say we would plan on it "when we need it" - We will support TLS 1.3 as it stabilizes, but at this stage I couldn't say when/if particular OpenSSL'isms might be supported. BoringSSL hasn't pulled in X509_NAME_get0_der either yet - so I think we will be taking what I would describe as a cautious and selective approach to new features from OpenSSL - During the same time as we've moved from about 750,000 of code at the fork to about 350,000 - OpenSSL is now over 1,000,000 lines - So we're probably not going to be about wholesale code importing from OpenSSL - We will be taking things selectively and with a degree of caution. Of note - we *do* support a newer API - libtls - which may be more than fine for most of OpenLDAP's needs: See http://man.openbsd.org/OpenBSD-current/man3/tls_init.3 and/or http://www.openbsd.org/papers/libtls-fsec-2015/ On Mon, Jun 20, 2016 at 09:21:43AM +0000, Connor Taffe wrote: > Hey, > > Does LibreSSL plan to implement the OpenSSL v1.1 API? > > I've submitted a patch to OpenLDAP to allow compilation with LibreSSL > v2.4.1. The patch currently checks if LIBRESSL_VERSION_NUMBER is defined > and if so uses the fallback code for versions of OpenSSL < 1.1. > > The maintainers would like to cap the version on the LibreSSL check if > implementation of the OpenSSL v1.1 API is planned. > > Specifically (to this case) OpenSSL added the SSL_CTX_up_ref function in > commit c5ebfcab713a82a1d46a51c8c2668c419425b387 in March of this year, and > added X509_NAME_get0_der in commit 7ab507495b86371756575d606af556b4fd74e27a > in January of this year. > > ---------- Forwarded message --------- > From: Howard Chu <hyc(a)symas.com> > Date: Mon, Jun 20, 2016 at 1:38 AM > Subject: Re: (ITS#8445) LibreSSL v2.4 compile > To: Connor Taffe <cpaynetaffe(a)gmail.com>, <openldap-its(a)openldap.org> > > > Connor Taffe wrote: > > Fixed, attached is a patch. > > I'm a bit concerned that you're only checking for the existence of LIBRESSL > instead of actually comparing the version number. Since the OpenSSL change > is > based on their v1.1 API, do you know if/when LibreSSL plans to adopt the > new API? > > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <hyc(a)symas.com > > <mailto:hyc@symas.com>> wrote: > > > > cpaynetaffe(a)gmail.com <mailto:cpaynetaffe@gmail.com> wrote: > > > Full_Name: Connor Taffe > > > Version: master > > > OS: Ubuntu devel > > > URL: ftp://ftp.openldap.org/incoming/ > > > Submission from: (NULL) (50.25.160.41) > > > > > > > > > Compiling against LibreSSL v2.4.1 failed linking with > SSL_CTX_up_ref and > > > X509_NAME_get0_der undefined. I added checking if > > LIBRESSL_VERSION_NUMBER to the > > > same conditional compilation ifs that are defined for old versions > of > > OpenSSL. > > > > > > https://github.com/cptaffe/openldap > > > > Please read the Developer Guidelines. I'm not going to pull an > arbitrary repo > > to find someone's patch. > > > > http://www.openldap.org/devel/contributing.html > > > > -- > > -- Howard Chu > > CTO, Symas Corp. http://www.symas.com > > Director, Highland Sun http://highlandsun.com/hyc/ > > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --001a113faca2cd5c170535ccd806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This is LibreSSL's response.<br><br><div class=3D"gmai= l_quote"><div dir=3D"ltr">---------- Forwarded message ---------<br>From: B= ob Beck <<a href=3D"mailto:beck@obtuse.com">beck(a)obtuse.com</a>><br>D= ate: Tue, Jun 21, 2016 at 11:45 AM<br>Subject: Re: OpenSSL v1.1 API<br>To: = Connor Taffe <<a href=3D"mailto:cpaynetaffe@gmail.com">cpaynetaffe@gmail= .com</a>><br>Cc: <<a href=3D"mailto:libressl@openbsd.org">libressl@o= penbsd.org</a>><br></div><br><br><br> I would say we would plan on it=C2=A0 "when we need it" - We will= support TLS 1.3 as<br> it stabilizes, but at this stage I couldn't say when/if particular Open= SSL'isms<br> might be supported.<br> <br> BoringSSL hasn't pulled in X509_NAME_get0_der either yet - so I think w= e will<br> be taking what I would describe as a cautious and selective approach to<br> new features from OpenSSL - During the same time as we've moved from ab= out<br> 750,000 of code at the fork to about 350,000 - OpenSSL is now over 1,000,00= 0<br> lines - So we're probably not going to be about wholesale code importin= g<br> from OpenSSL - We will be taking things selectively and with a degree<br> of caution.<br> <br> Of note - we *do* support a newer API - libtls - which may be more<br> than fine for most of OpenLDAP's needs:<br> <br> See<br> <a href=3D"http://man.openbsd.org/OpenBSD-current/man3/tls_init.3" rel=3D"n= oreferrer" target=3D"_blank">http://man.openbsd.org/OpenBSD-current/man3/tl= s_init.3</a><br> and/or<br> <a href=3D"http://www.openbsd.org/papers/libtls-fsec-2015/" rel=3D"noreferr= er" target=3D"_blank">http://www.openbsd.org/papers/libtls-fsec-2015/</a><b= r> <br> <br> On Mon, Jun 20, 2016 at 09:21:43AM +0000, Connor Taffe wrote:<br> > Hey,<br> ><br> > Does LibreSSL plan to implement the OpenSSL v1.1 API?<br> ><br> > I've submitted a patch to OpenLDAP to allow compilation with Libre= SSL<br> > v2.4.1. The patch currently checks if LIBRESSL_VERSION_NUMBER is defin= ed<br> > and if so uses the fallback code for versions of OpenSSL < 1.1.<br> ><br> > The maintainers would like to cap the version on the LibreSSL check if= <br> > implementation of the OpenSSL v1.1 API is planned.<br> ><br> > Specifically (to this case) OpenSSL added the SSL_CTX_up_ref function = in<br> > commit c5ebfcab713a82a1d46a51c8c2668c419425b387 in March of this year,= and<br> > added X509_NAME_get0_der in commit 7ab507495b86371756575d606af556b4fd7= 4e27a<br> > in January of this year.<br> ><br> > ---------- Forwarded message ---------<br> > From: Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank= ">hyc(a)symas.com</a>><br> > Date: Mon, Jun 20, 2016 at 1:38 AM<br> > Subject: Re: (ITS#8445) LibreSSL v2.4 compile<br> > To: Connor Taffe <<a href=3D"mailto:cpaynetaffe@gmail.com" target= =3D"_blank">cpaynetaffe(a)gmail.com</a>>, <<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>><br> ><br> ><br> > Connor Taffe wrote:<br> > > Fixed, attached is a patch.<br> ><br> > I'm a bit concerned that you're only checking for the existenc= e of LIBRESSL<br> > instead of actually comparing the version number. Since the OpenSSL ch= ange<br> > is<br> > based on their v1.1 API, do you know if/when LibreSSL plans to adopt t= he<br> > new API?<br> ><br> > > On Sun, Jun 19, 2016 at 8:02 PM Howard Chu <<a href=3D"mailto:= hyc(a)symas.com" target=3D"_blank">hyc(a)symas.com</a><br> > > <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc= @symas.com</a>>> wrote:<br> > ><br> > >=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:cpaynetaffe@gmail.com" targe= t=3D"_blank">cpaynetaffe(a)gmail.com</a> <mailto:<a href=3D"mailto:cpaynet= affe(a)gmail.com" target=3D"_blank">cpaynetaffe(a)gmail.com</a>> wrote:<br> > >=C2=A0 =C2=A0 =C2=A0 > Full_Name: Connor Taffe<br> > >=C2=A0 =C2=A0 =C2=A0 > Version: master<br> > >=C2=A0 =C2=A0 =C2=A0 > OS: Ubuntu devel<br> > >=C2=A0 =C2=A0 =C2=A0 > URL: <a href=3D"ftp://ftp.openldap.org/i= ncoming/" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incom= ing/</a><br> > >=C2=A0 =C2=A0 =C2=A0 > Submission from: (NULL) (50.25.160.41)<b= r> > >=C2=A0 =C2=A0 =C2=A0 ><br> > >=C2=A0 =C2=A0 =C2=A0 ><br> > >=C2=A0 =C2=A0 =C2=A0 > Compiling against LibreSSL v2.4.1 failed= linking with<br> > SSL_CTX_up_ref and<br> > >=C2=A0 =C2=A0 =C2=A0 > X509_NAME_get0_der undefined. I added ch= ecking if<br> > >=C2=A0 =C2=A0 =C2=A0LIBRESSL_VERSION_NUMBER to the<br> > >=C2=A0 =C2=A0 =C2=A0 > same conditional compilation ifs that ar= e defined for old versions<br> > of<br> > >=C2=A0 =C2=A0 =C2=A0OpenSSL.<br> > >=C2=A0 =C2=A0 =C2=A0 ><br> > >=C2=A0 =C2=A0 =C2=A0 > <a href=3D"https://github.com/cptaffe/op= enldap" rel=3D"noreferrer" target=3D"_blank">https://github.com/cptaffe/ope= nldap</a><br> > ><br> > >=C2=A0 =C2=A0 =C2=A0Please read the Developer Guidelines. I'm = not going to pull an<br> > arbitrary repo<br> > >=C2=A0 =C2=A0 =C2=A0to find someone's patch.<br> > ><br> > >=C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.openldap.org/devel/contr= ibuting.html" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/= devel/contributing.html</a><br> > ><br> > >=C2=A0 =C2=A0 =C2=A0--<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http= ://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas.com= </a><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href= =3D"http://highlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http:= //highlandsun.com/hyc/</a><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a hre= f=3D"http://www.openldap.org/project/" rel=3D"noreferrer" target=3D"_blank"= >http://www.openldap.org/project/</a><br> > ><br> ><br> ><br> > --<br> >=C2=A0 =C2=A0 -- Howard Chu<br> >=C2=A0 =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= <a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http:= //www.symas.com</a><br> >=C2=A0 =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http= ://highlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highla= ndsun.com/hyc/</a><br> >=C2=A0 =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.ope= nldap.org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openlda= p.org/project/</a><br> </div></div> --001a113faca2cd5c170535ccd806--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs