- openldap-bugs - openldap.org

Re: (ITS#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by quanah＠symas.com 22 Sep '17

22 Sep '17

--On Wednesday, September 20, 2017 4:06 AM +0000 djkurtz(a)google.com wrote: >> Out of curiosity, what OS were you compiling on that didn't have >> /dev/urandom available? > > This occurs when cross compiling. See: > https://github.com/openldap/openldap/blob/master/configure.in#L2197 Perfect, tyvm! Patch seems like it should be fairly straight forward. If I send you one, would you be able to test it? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8737) LMDB allows creation of multiple databases in same directory
by hyc＠symas.com 22 Sep '17

22 Sep '17

Aleksey Kamensky wrote: > And on the other hand saying "not an issue because no one else does it this > way" is not a good approach IMO as it only stimulates copying and does not > help those offering improvements. Feel free to submit a patch improving the situation. -- -- 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#8739) Better check for fsync on FreeBSD
by gahr＠gahr.ch 22 Sep '17

22 Sep '17

Full_Name: Pietro Cerutti Version: lmdb 0.9.21 OS: FreeBSD 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.191.176.33) This patch allows for a finer-grained control over which FreeBSD versions support fdatasync. This allows us to get rid of a custom patch in our ports. --- mdb.c.orig 2017-06-01 16:51:10 UTC +++ mdb.c @@ -125,6 +125,8 @@ typedef SSIZE_T ssize_t; # define MDB_FDATASYNC fsync #elif defined(ANDROID) # define MDB_FDATASYNC fsync +#elif defined(__FreeBSD_version) && __FreeBSD_version < 1101000 +# define MDB_FDATASYNC fsync #endif #ifndef _WIN32

1 0

Re: (ITS#8737) LMDB allows creation of multiple databases in same directory
by aleksey.kamensky＠gmail.com 22 Sep '17

22 Sep '17

--94eb2c075988d198060559c39077 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 20, 2017 at 7:28 PM, Howard Chu <hyc(a)symas.com> wrote: > aleksey.kamensky(a)gmail.com wrote: > >> Full_Name: Alexey Kamenskiy >> Version: 2.4.45 >> OS: CentOS Linux release 7.3.1611 (Core) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (220.248.35.50) >> >> >> Setting up fresh 2.4.45 with MDB noticed that MDB does allow to create >> multiple >> databases in the same directory (noticed by mistake of creating multiple >> MDBs in >> default /var/lib/ldap). >> >> It shows no error and no any warning. After this ALL of the databases are >> writeable and readable. On reading the results returned for all 3 >> databases (and >> not for the DIT specified in ldapsearch -b). >> > > None of the other backends protect from this either. (Nor can they, since > any individual backend doesn't know anything about any other backend's > configuration.) Not a bug. You are right that other backends (I am talking here hdb/bdb) do not explicitly check for this, but those backends will produce error on attempt to read/write into database created in the directory where DB already exists. LMDB just works in this case and returns bad results if try to read. Even if not intentionally those errors serve as a reminder that one should not create two DBs in same directory. And on the other hand saying "not an issue because no one else does it this way" is not a good approach IMO as it only stimulates copying and does not help those offering improvements. --94eb2c075988d198060559c39077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Wed, Sep 20, 2017 at 7:28 PM, Howard Chu <span dir=3D"ltr"><<a hr= ef=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:aleksey.kamensky= @gmail.com" target=3D"_blank">aleksey.kamensky(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Alexey Kamenskiy<br> Version: 2.4.45<br> OS: CentOS Linux release 7.3.1611 (Core)<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incomin<wbr>g/</a><br> Submission from: (NULL) <a href=3D"tel:%28220.248.35.50" value=3D"+12202483= 550" target=3D"_blank">(220.248.35.50</a>)<br> <br> <br> Setting up fresh 2.4.45 with MDB noticed that MDB does allow to create mult= iple<br> databases in the same directory (noticed by mistake of creating multiple MD= Bs in<br> default /var/lib/ldap).<br> <br> It shows no error and no any warning. After this ALL of the databases are<b= r> writeable and readable. On reading the results returned for all 3 databases= (and<br> not for the DIT specified in ldapsearch -b).<br> </blockquote> <br> None of the other backends protect from this either. (Nor can they, since a= ny individual backend doesn't know anything about any other backend&#39= ;s configuration.) Not a bug.</blockquote><div><br></div><div>You are right= that other backends (I am talking here hdb/bdb) do not explicitly check fo= r this, but those backends will produce error on attempt to read/write into= database created in the directory where DB already exists. LMDB just works= in this case and returns bad results if try to read.</div><div><br></div><= div>Even if not intentionally those errors serve as a reminder that one sho= uld not create two DBs in same directory.</div><div><br></div><div>And on t= he other hand saying "not an issue because no one else does it this wa= y" is not a good approach IMO as it only stimulates copying and does n= ot help those offering improvements.</div><div>=C2=A0</div></div></div></di= v> --94eb2c075988d198060559c39077--

1 0

(ITS#8738) test066-autoca aborts with TLS error
by dieter＠dkluenter.de 20 Sep '17

20 Sep '17

Full_Name: Dieter Kluenter Version: OS: OpenSUSE URL: ftp://ftp.openldap.org/incoming/dkluenter-20-07-17-autoca.patch Submission from: (NULL) (93.214.247.185) test066-autoca aborts with adding new entry "cn=module,cn=config" adding new entry "olcOverlay=autoca,olcDatabase={1}mdb,cn=config" dn: cn=localhost,ou=Servers,dc=example,dc=com userCertificate;binary: userPrivateKey;binary: ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate this small patch solves this error

1 0

Re: (ITS#8737) LMDB allows creation of multiple databases in same directory
by hyc＠symas.com 20 Sep '17

20 Sep '17

aleksey.kamensky(a)gmail.com wrote: > Full_Name: Alexey Kamenskiy > Version: 2.4.45 > OS: CentOS Linux release 7.3.1611 (Core) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.248.35.50) > > > Setting up fresh 2.4.45 with MDB noticed that MDB does allow to create multiple > databases in the same directory (noticed by mistake of creating multiple MDBs in > default /var/lib/ldap). > > It shows no error and no any warning. After this ALL of the databases are > writeable and readable. On reading the results returned for all 3 databases (and > not for the DIT specified in ldapsearch -b). None of the other backends protect from this either. (Nor can they, since any individual backend doesn't know anything about any other backend's configuration.) Not a bug. -- -- 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#8737) LMDB allows creation of multiple databases in same directory
by aleksey.kamensky＠gmail.com 20 Sep '17

20 Sep '17

Full_Name: Alexey Kamenskiy Version: 2.4.45 OS: CentOS Linux release 7.3.1611 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.248.35.50) Setting up fresh 2.4.45 with MDB noticed that MDB does allow to create multiple databases in the same directory (noticed by mistake of creating multiple MDBs in default /var/lib/ldap). It shows no error and no any warning. After this ALL of the databases are writeable and readable. On reading the results returned for all 3 databases (and not for the DIT specified in ldapsearch -b).

1 0

Re: (ITS#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by djkurtz＠google.com 20 Sep '17

20 Sep '17

On Tue, Sep 19, 2017 at 4:43 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Friday, July 07, 2017 8:45 AM +0000 djkurtz(a)google.com wrote: > >> Full_Name: Daniel Jonathan Kurtz >> Version: 2.4.45 >> OS: linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) > > > Out of curiosity, what OS were you compiling on that didn't have /dev/urandom available? > > --Quanah This occurs when cross compiling. See: https://github.com/openldap/openldap/blob/master/configure.in#L2197 > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Daniel Kurtz | Software Engineer | djkurtz(a)google.com | 650.204.0722

1 0

Re: (ITS#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by quanah＠symas.com 20 Sep '17

20 Sep '17

--On Friday, July 07, 2017 8:45 AM +0000 djkurtz(a)google.com wrote: > Full_Name: Daniel Jonathan Kurtz > Version: 2.4.45 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) Out of curiosity, what OS were you compiling on that didn't have /dev/urandom available? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8736) Add test script for cn=config replication using delta-sync
by quanah＠openldap.org 18 Sep '17

18 Sep '17

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Currently test059 shows how replication of cn=config can work for a replica, using back-ldif and standard syncrepl, but we do not have a corresponding script using delta-syncrepl. We should similarly have a corresponding test script for cn=config MMR using delta-syncrepl for the cn=config db.

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by ondra＠mistotebe.net 18 Sep '17

18 Sep '17

> IMO using recursive mutexes means your code is broken. We introduced these for > accesslog.c but in fact we could avoid them at zero cost. Also I don't see the > relevance of libevent to this discussion. We use our own event mechanism and > it is more efficient than libevent. libevent is a dependency for the load balancer that I intend to propose for integration into the project after all the relevant dependencies have come in. There is a new version of this patch that provides an implementation on each platform or defers to the existing one (as per each platform's documentation). Untested except on POSIX and most of them seem pretty arcane anyway. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170918-ITS8638-libldap_r-re… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 Sep '17

16 Sep '17

I've been running 2.4.44 with the test patch since May and haven't seen a crash since, for what that's worth. We upgraded to 2.4.45 last week, without that patch. I'm going to see if the crash shows up again, and if it does, apply the patch to 2.4.45 and see if it goes away again. Thanks...

1 0

Re: (ITS#8731) Variadic Debug() macro
by ondra＠mistotebe.net 15 Sep '17

15 Sep '17

On Tue, Sep 12, 2017 at 12:55:20PM +0000, okuznik(a)symas.com wrote: > The patch series in the linked archive changes the logging macros to > be fully variadic: Hi Kurt, the only opposition to going ahead with a change like this I can find[0] has been based on the fact we'd be dropping support for C90 and it is your voice that puts concrete arguments forward as a reason for this. It would seem that no notable platforms remain where the host compiler would not be able to cope. With that in mind, might I suggest we decide it is time to require C99 support from 2.5 onwards? Thanks, [0] http://www.openldap.org/lists/openldap-devel/200801/msg00059.html -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by michael＠stroeder.com 14 Sep '17

14 Sep '17

come(a)opensides.be wrote: > I'm not sure I understand the outcome of the discussion > here, why i s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the > supportedControl returned by the rootDSE? > (1.3.6.1.4.1.42.2.27.8.5.1 being > LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to > know that the server supports ppolicy. Frankly I can't imagine how to make it more clear than I already did. Please re-read my follow-up here: https://www.openldap.org/its/index.cgi?findid=8208#followup2 Especially note that the original poster did *not* mention OID 1.3.6.1.4.1.42.2.27.8.5.1 to be missing. (It's present in all my OpenLDAP servers.) The original poster asked for another outdated password policy mechanism. Ciao, Michael.

1 0

Re: (ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
by michael＠stroeder.com 14 Sep '17

14 Sep '17

sean.haugh(a)vertivco.com wrote: > I'm seeing a significant delay (32s) when setting > `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in > resolv.conf. We initially discovered the issue in 2.4.42 > although I've confirmed it is present in 2.4.45. AFAIK it is > not present in 2.4.23. I assume you see a delay at the client-side. Are you sure that it is not something caused by the TLS library updated in the mean-time? Which one is used by the client? You should re-test with server certs without any URLs (AIA, CRLDP extensions etc.) which might be accessed by your TLS lib. You could also monitor the DNS traffic. Some resolvers allow to switch on query logging. Or tcpdump or similar. And BTW: The most likely answer is that your resolver should always be up and running. Sometimes a local caching resolver helps to overcome upstream resolver outage. Ciao, Michael.

1 0

(ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
by sean.haugh＠vertivco.com 14 Sep '17

14 Sep '17

Full_Name: Sean Haugh Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (143.166.81.254) I'm seeing a significant delay (32s) when setting `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in resolv.conf. We initially discovered the issue in 2.4.42 although I've confirmed it is present in 2.4.45. AFAIK it is not present in 2.4.23.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by come＠opensides.be 14 Sep '17

14 Sep '17

Hello, I=E2=80=99m not sure I understand the outcome of the discussion here, why i= s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the supportedControl returned by th= e rootDSE? (1.3.6.1.4.1.42.2.27.8.5.1 being LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to know that the server supports ppolicy. C=C3=B4me

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠symas.com 13 Sep '17

13 Sep '17

Hi Bryan, I managed to track down a copy of your patch, and uploaded it to the OpenLDAP FTP server as bryan-duncan-its6300.patch. I will see about getting this updated for current OpenLDAP, for possible inclusion in OpenLDAP 2.5. Regards, Quanah --On Monday, September 11, 2017 11:45 PM +0000 quanah(a)fast-mail.org wrote: > Hi Bryan, > > Unfortunately this patch is no longer available with Apple's switch to > iCloud. Would you be able to upload it to the OpenLDAP FTP server? > > Thanks, > Quanah > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 13 Sep '17

13 Sep '17

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-170913.patch Submission from: (NULL) (87.227.214.182) This patch contains the fixes for all issues discovered and fixed since the initial submission of back-asyncmeta. These include memory leaks, stability issues, segfaults and functional bugs. IPR: 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 2017 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#8733) liblber value extraction enhancements
by ondra＠openldap.org 13 Sep '17

13 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170913-ber_skip_raw-ber_dec… Submission from: (NULL) (82.10.24.68) When extracting parts of a BerElement, one might want to pull out a valid ber-encoded buffer. Also, there is no way to ber-decode an integer from a berval. These patches provide and expose that functionality. The attached patches have been authored by Hallvard with a few fixes by me, I have kept his name as the author.

1 0

(ITS#8732) LDAP_CIRCLEQ improvements
by ondra＠openldap.org 13 Sep '17

13 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170913-LDAP_CIRCLEQ.patch Submission from: (NULL) (82.10.24.68) The CIRCLEQ macros are incomplete and not very useful on their own, but when providing a few more that allow rotating it, they are. Patch to that effect is attached. They could probably be made a bit more efficient as well, though.

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by hyc＠symas.com 12 Sep '17

12 Sep '17

Ryan Tandy wrote: > On Tue, Sep 12, 2017 at 08:24:15PM +0000, hyc(a)symas.com wrote: >> I don't have documentation for sd_notify() on my machine > > https://www.freedesktop.org/software/systemd/man/sd_notify.html > >> - what does it return if systemd isn't running at the moment? What does it >> return if the current program wasn't started by systemd (and thus, the >> notification is irrelevant)? > > 0 in both of these cases (assuming there is not an unrelated NOTIFY_SOCKET env > var). However, it also says: > >> In order to support both service managers that implement this scheme and >> those which do not, it is generally recommended to ignore the return value >> of this call." > > and the current patch doesn't follow that recommendation, since it does check > the return value. I don't feel strongly either way about that. OK. You realize how egregiously gross this kind of API design is? "Oh, yeah, we return a value, but properly written programs should ignore it." Everything about this makes me nauseous. -- -- 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#8707) slapd: Add systemd service notification support
by ryan＠nardis.ca 12 Sep '17

12 Sep '17

On Tue, Sep 12, 2017 at 08:24:15PM +0000, hyc(a)symas.com wrote: >I don't have documentation for sd_notify() on my machine https://www.freedesktop.org/software/systemd/man/sd_notify.html >- what does it return if systemd isn't running at the moment? What does >it return if the current program wasn't started by systemd (and thus, >the notification is irrelevant)? 0 in both of these cases (assuming there is not an unrelated NOTIFY_SOCKET env var). However, it also says: >In order to support both service managers that implement this scheme >and those which do not, it is generally recommended to ignore the >return value of this call." and the current patch doesn't follow that recommendation, since it does check the return value. I don't feel strongly either way about that. >It strikes me that this code should only be invoked if slapd was actually >started by systemd. As I understand it, sd_notify() should be a no-op (no error) if NOTIFY_SOCKET is not set. I don't think we should check NOTIFY_SOCKET ourselves; it's to some extent an implementation detail.

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by hyc＠symas.com 12 Sep '17

12 Sep '17

michael(a)stroeder.com wrote: > Howard Chu wrote: >> If no one has any other reasons to offer, I'm inclined to reject >> and close this ITS. > > Note that the systemd unit file was only a little detail in this > ITS. The most important part is the C code change. OK. Looking at the patch: +dnl +dnl Check for systemd +dnl +WITH_SYSTEMD=no +ol_link_systemd=no +if test $ol_with_systemd != no ; then + AC_CHECK_HEADERS(systemd/sd-daemon.h) + + if test $ac_cv_header_systemd_sd_daemon_h = yes; then + AC_CHECK_LIB(systemd, sd_notify, + [ol_link_systemd="-lsystemd"]) + fi + + if test $ol_link_systemd = no ; then + if test $ol_with_systemd != auto ; then + AC_MSG_ERROR([Could not locate systemd]) + else + AC_MSG_WARN([Could not locate systemd]) + AC_MSG_WARN([systemd service notification not supported!]) + fi + else + AC_DEFINE(HAVE_SYSTEMD,1,[define if you have systemd]) + SYSTEMD_LIBS="$ol_link_systemd" + WITH_SYSTEMD=yes + fi +fi + There should not be any warning if with-systemd is defaulted to auto and it's not found. It should be silently ignored. This isn't like SASL, which is an explicit part of the LDAP spec and therefore has a warning in its absence. +#ifdef HAVE_SYSTEMD + rc = sd_notifyf( 1, + "READY=1\n" + "STATUS=slapd: ready to serve connections...\n" + "MAINPID=%lu", + (unsigned long) getpid() ); + if ( rc < 0 ) + Debug( LDAP_DEBUG_ANY, + "systemd sd_notify failed (%d)\n", rc, 0, 0 ); +#endif /* HAVE_SYSTEMD */ + I don't have documentation for sd_notify() on my machine - what does it return if systemd isn't running at the moment? What does it return if the current program wasn't started by systemd (and thus, the notification is irrelevant)? It strikes me that this code should only be invoked if slapd was actually started by systemd. In particular, I don't want to see a lot of "sd_notify failed" messages in our logs, for manually started slapd processes. -- -- 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#8707) slapd: Add systemd service notification support
by michael＠stroeder.com 12 Sep '17

12 Sep '17

Howard Chu wrote: > If no one has any other reasons to offer, I'm inclined to reject > and close this ITS. Note that the systemd unit file was only a little detail in this ITS. The most important part is the C code change. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs