openldap-bugs January 2016

openldap-bugs@openldap.org

22 participants
58 discussions

(ITS#8362) Broken Anchors in 2.4 Administrators Guide
by l.wolf＠xlea.se 27 Jan '16

27 Jan '16

Full_Name: L. Wolf Version: 2.4 OS: doesn't matter URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.152.26.226) Section 4.2 -> Anchors "BerkeleyDB" correct href: http://www.oracle.com/technetwork/database/database-technologies/berkeleydb… Section 4.2 -> Anchor "http://www.oracle.com/technology/software/products/berkeley-db/index.html" (also applies to PDF version) correct href: http://www.oracle.com/technetwork/database/database-technologies/berkeleydb…

1 0

Re: (ITS#8354) syncprov segv
by tpretz＠gmail.com 27 Jan '16

27 Jan '16

On Tue, Jan 26, 2016 at 6:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Saturday, January 23, 2016 2:43 PM +0000 tpretz(a)gmail.com wrote: > >> Thanks, >> >> Essentially the same patch as i had (destroyed sop->s_mutex in abandon >> check rather than init later). >> >> I did place the o_abandon test under the while( si->si_active ) loop >> instead of above just to ensure the check is under the same lock hold >> as the list modification. >> >> Ill grab whats in git and start tests on monday > > > Hi Tom, > > Are you able to confirm if the fix is good? I'm working on 2.4.44, and want > to be sure this fix is included. I'v had an instance running with this patch for a few days, no SEGV, looks good to me. Thanks > > Thanks! > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8353) OpenLDAP won't compile with OpenSSL 1.1.X
by hyc＠symas.com 26 Jan '16

26 Jan '16

Howard Chu wrote: > m-oldap(a)bodyfour.uk wrote: >> Full_Name: Mitchell Blank >> Version: 2.4.43 >> OS: linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.169.198.86) >> >> >> Recently a couple alpha releases for OpenSSL 1.1.X have been posted on >> www.openssl.org with the request that software be tested against them prior to >> release. > > Thanks for the report. There are clearly 2 issues the OpenSSL folks will have > to resolve before this will work. > > https://mta.openssl.org/pipermail/openssl-dev/2016-January/004362.html > https://mta.openssl.org/pipermail/openssl-dev/2016-January/004365.html The remaining unresolved issue is in their tracker at https://rt.openssl.org/Ticket/Display.html?id=4274 -- -- 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#8361) mdb_strerror() issues
by h.b.furuseth＠usit.uio.no 26 Jan '16

26 Jan '16

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.17 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard Unix issues: mdb_strerror uses strerror(), which can sprintf(buf, "Error %d", err) to a thread-unsafe global buffer. In other cases, strerror hopefully returns a pointer to a constant string. This means we can make it hopefully-threadsafe on Unix by documenting "mdb_strerror() should only be used for codes returned by mdb_*() calls". Windows issues: mdb_strerror()'s doc says it extends strerror(). Wrong on Windows. It terminates messages with CRLF. Maybe programs written by Windows users will expect this, but not those from Unix folks. Fix: Strip trailing CRLF, or include FORMAT_MESSAGE_MAX_WIDTH_MASK and then strip trailing space which gets appended instead. The FormatMessage doc says this mask ignores "regular" line breaks but stores "hard-coded" line breaks, I don't know what that means. (Can some system messages have CRLFs inside them?) The pad[] hack breaks if the compiler rearranges locals vars. Fix: Join pad and buf in a struct/array, and drop the (va_list *)pad hack. That hack must be documented. Or replaced, or made a global option. I note that OpenLDAP lutil_debug() does use more tha 4K stack like the mdb_strerror() comment says it shouldn't. Maybe it'd be best to use a thread key by default, but if mdb_set_scarce() or something is called before any mdb_env_create() call, then it will use the current code. But - if mdb_strerror() is called before that again, it'll... init the key itself? Sigh. Also we could add "char *mdb_strerror_r()" which *may* use the user-provided buffer, like the glibc version. Should also add a constant MDB_STRERROR_BUFSIZE as the recommended/minimum buffer size, instead of expecting the programmer to guess the value. That'll at least provide an officially sane alternative. Except - possibly this function would still use strerror() rather than strerror_r() on Unix. The Gnulib (not glibc) comments about strerror_r() portability/bugs are depressing, though hopefully most are outdated: https://www.gnu.org/software/gnulib/manual/html_node/strerror_005fr.html

1 0

Re: (ITS#8354) syncprov segv
by quanah＠zimbra.com 26 Jan '16

26 Jan '16

--On Saturday, January 23, 2016 2:43 PM +0000 tpretz(a)gmail.com wrote: > Thanks, > > Essentially the same patch as i had (destroyed sop->s_mutex in abandon > check rather than init later). > > I did place the o_abandon test under the while( si->si_active ) loop > instead of above just to ensure the check is under the same lock hold > as the list modification. > > Ill grab whats in git and start tests on monday Hi Tom, Are you able to confirm if the fix is good? I'm working on 2.4.44, and want to be sure this fix is included. Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8360) apparent MDB corruption when hitting maxsize
by hyc＠symas.com 26 Jan '16

26 Jan '16

Howard Chu wrote: > peter.van.dijk(a)powerdns.com wrote: >> Full_Name: Peter van Dijk >> Version: 2.4.43 >> OS: Mac OS X 10.10.5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:610:666:0:c92b:7aa7:bc73:c430) >> >> >> The procedure follow is fully repeatable with consistent problematic results >> for >> me. > > Unable to reproduce this on Linux using RE24. I had the sequence of steps a bit wrong - running slapcat immediately after ldapmodify masked the problem. Fixed now in git. -- -- 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#8360) apparent MDB corruption when hitting maxsize
by hyc＠symas.com 26 Jan '16

26 Jan '16

peter.van.dijk(a)powerdns.com wrote: > Full_Name: Peter van Dijk > Version: 2.4.43 > OS: Mac OS X 10.10.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:610:666:0:c92b:7aa7:bc73:c430) > > > The procedure follow is fully repeatable with consistent problematic results for > me. Unable to reproduce this on Linux using RE24. > (1) ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.43.tgz, > installed via osx homebrew with configure flags > --prefix=/usr/local/Cellar/openlp%p/2.4.43 --sysconfdir=/usr/local/etc > --localstatedir=/usr/local/var > > (2) config and related files as uploaded on the given URL (cosine.schema is > unedited but included for completeness) > > (3) /usr/local/var/openldap-data/ is empty > > (4) sudo /usr/local/opt/openldap/libexec/slapd -d 255 -u peter 2> slapd.log > > (5) ldapmodify -D 'uid=peter,o=habbie' -w secret -c < named.conf.ldif 2> > ldapmodify.log ; ldapdelete -D 'uid=peter,o=habbie' -w secret -r ou=dns,o=habbie > 2> ldapdelete.log > modify is unhappy, initially because of some unknown attributes (thish is why I > used -c), then later because it is hitting the MDB maxsize of 10 megabytes. > ldapdelete then fails to delete the ou=dns tree due to MDB errors > > (6) increasing maxsize after this 'corruption' has happened does NOT enable > ldapdelete to suddenly work ldapdelete works fine for me after raising maxsize. > > (7) (with slapd stopped, not sure it matters): $ > /usr/local/opt/openldap/sbin/slapcat outputs 191771 lines to stdout before > aborting with: > 56a63063 mdb_entry_decode: attribute index 24 not recognized > Segmentation fault: 11 Never saw this, slapcat runs to completion with no complaints. -- -- 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#8360) apparent MDB corruption when hitting maxsize
by peter.van.dijk＠powerdns.com 25 Jan '16

25 Jan '16

Apparently I did not actually enter the right URL. All data is at https://downloads.powerdns.com/tmp/openldap-its-20160125/

1 0

Re: (ITS#8360) apparent MDB corruption when hitting maxsize
by peter.van.dijk＠powerdns.com 25 Jan '16

25 Jan '16

The configure line got messed up somewhere (probably my terminal), should be ==> ./configure --prefix=/usr/local/Cellar/openldap/2.4.43 --sysconfdir=/usr/local/etc --localstatedir=/usr/local/var

1 0

(ITS#8360) apparent MDB corruption when hitting maxsize
by peter.van.dijk＠powerdns.com 25 Jan '16

25 Jan '16

Full_Name: Peter van Dijk Version: 2.4.43 OS: Mac OS X 10.10.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:610:666:0:c92b:7aa7:bc73:c430) The procedure follow is fully repeatable with consistent problematic results for me. (1) ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.43.tgz, installed via osx homebrew with configure flags --prefix=/usr/local/Cellar/openlp%p/2.4.43 --sysconfdir=/usr/local/etc --localstatedir=/usr/local/var (2) config and related files as uploaded on the given URL (cosine.schema is unedited but included for completeness) (3) /usr/local/var/openldap-data/ is empty (4) sudo /usr/local/opt/openldap/libexec/slapd -d 255 -u peter 2> slapd.log (5) ldapmodify -D 'uid=peter,o=habbie' -w secret -c < named.conf.ldif 2> ldapmodify.log ; ldapdelete -D 'uid=peter,o=habbie' -w secret -r ou=dns,o=habbie 2> ldapdelete.log modify is unhappy, initially because of some unknown attributes (thish is why I used -c), then later because it is hitting the MDB maxsize of 10 megabytes. ldapdelete then fails to delete the ou=dns tree due to MDB errors (6) increasing maxsize after this 'corruption' has happened does NOT enable ldapdelete to suddenly work (7) (with slapd stopped, not sure it matters): $ /usr/local/opt/openldap/sbin/slapcat outputs 191771 lines to stdout before aborting with: 56a63063 mdb_entry_decode: attribute index 24 not recognized Segmentation fault: 11 (8) as requested by hyc on IRC, copying here for completeness $ mdb_dump -p -s ad2i /usr/local/var/openldap-data/ VERSION=3 format=print database=ad2i type=btree mapsize=10485760 maxreaders=126 tetegerkey=1 db_pagesize=4096 HEADER=END \01\00\00\00 objectClass \02\00\00\00 o \03\00\00\00 structuralObjectClass \04\00\00\00 entryUUID \05\00\00\00 creatorsName \06\00\00\00 createTimestamp \07\00\00\00 entryCSN \08\00\00\00 modifiersName \09\00\00\00 modifyTimestamp \0a\00\00\00 ou \0b\00\00\00 dc \0c\00\00\00 associatedDomain \0d\00\00\00 dNSTTL \0e\00\00\00 sOARecord \0f\00\00\00 nSRecord \10\00\00\00 mXRecord \11\00\00\00 aRecord \12\00\00\00 cMEReRecord \13\00\00\00 LocRecord \14\00\00\00 hInfoRecord \15\00\00\00 tXTRecord \16\00\00\00 aAAARecord DATA=END

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2016