openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7544) liblmdb does not specify data lifetime
by h.b.furuseth＠usit.uio.no 19 Mar '13

19 Mar '13

Full_Name: Hallvard B Furuseth Version: 2.4.34 OS: URL: Submission from: (NULL) (193.157.249.58) Submitted by: hallvard I can't see that lmdb.h explains how long MDB_val data returned to the API remains valid: I know the data cannot be used after aborting/committing the txn. How about data in a dirty page - can future update operations in the same txn invalidate it?

1 0

Re: (ITS#7542) slapd segfault on modify
by m.gr＠gmx.de 18 Mar '13

18 Mar '13

On 03/18/2013 07:48 PM, Howard Chu wrote: > m.gr(a)gmx.de wrote: >> Full_Name: Matthias Grau >> Version: 2.4.34 >> OS: debian 6.7.0 x64 >> URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 >> Submission from: (NULL) (94.217.193.246) >> >> >> slapd can cause a segfault when sorting values in modify operation. >> Under rare circumstances modify.c:802: jstack += 2; can reach a value >> of greater >> 63 which leads to an overwritten pointer for AttributeDescription. > > Thanks for the report. > >> Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + >> 1 solves >> the segfault. But I don't think that's the correct solution. >> As shown here: >> http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc >> there should be a condition to break if jstack reaches the size of of >> istack. > > No. In a correct implementation, jstack can never exceed the size of > istack. > This was fixed in similar/identical code elsewhere, e.g. commit > bb36bdcd1c22d1fbc6575452ef5c9112715ab083 and > e1559100eb8e9a664cd68915e5acbf8caa334fa1 but for some reason we missed > these other instances. > > Fixed now in git master. Thanks for your fast solution. Problem is solved in git master.

1 0

(ITS#7543) Statslog "conn=-1 ... ACCEPT"
by h.b.furuseth＠usit.uio.no 18 Mar '13

18 Mar '13

Full_Name: Hallvard B Furuseth Version: 2.4.34 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard slapd logs "conn=-1 fd=.. ACCEPT" if the connection is closed before logging ACCEPT. This became more common recently. I'll fix it by moving Statslog into connection_init(), which knows the connection ID. Not fixing "ACCEPT" to always be logged before "close": It would need the Statslog() done before unlocking c->c_mutex, which looks like it could impact throughput.

1 0

Re: (ITS#7542) slapd segfault on modify
by hyc＠symas.com 18 Mar '13

18 Mar '13

m.gr(a)gmx.de wrote: > Full_Name: Matthias Grau > Version: 2.4.34 > OS: debian 6.7.0 x64 > URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 > Submission from: (NULL) (94.217.193.246) > > > slapd can cause a segfault when sorting values in modify operation. > Under rare circumstances modify.c:802: jstack += 2; can reach a value of greater > 63 which leads to an overwritten pointer for AttributeDescription. Thanks for the report. > Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + 1 solves > the segfault. But I don't think that's the correct solution. > As shown here: > http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc > there should be a condition to break if jstack reaches the size of of istack. No. In a correct implementation, jstack can never exceed the size of istack. This was fixed in similar/identical code elsewhere, e.g. commit bb36bdcd1c22d1fbc6575452ef5c9112715ab083 and e1559100eb8e9a664cd68915e5acbf8caa334fa1 but for some reason we missed these other instances. Fixed now in git master. -- -- 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#7542) slapd segfault on modify
by m.gr＠gmx.de 18 Mar '13

18 Mar '13

Full_Name: Matthias Grau Version: 2.4.34 OS: debian 6.7.0 x64 URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 Submission from: (NULL) (94.217.193.246) slapd can cause a segfault when sorting values in modify operation. Under rare circumstances modify.c:802: jstack += 2; can reach a value of greater 63 which leads to an overwritten pointer for AttributeDescription. Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + 1 solves the segfault. But I don't think that's the correct solution. As shown here: http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc there should be a condition to break if jstack reaches the size of of istack. root@debian:/root# gdb /usr/local/libexec/slapd GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/libexec/slapd...done. (gdb) r -h ldap://localhost:389 -f /root/slapd.conf -d 0 Starting program: /usr/local/libexec/slapd -h ldap://localhost:389 -f /root/slapd.conf -d 0 [Thread debugging using libthread_db enabled] [New Thread 0x7ffff6dc8700 (LWP 3728)] [New Thread 0x7ffff65c7700 (LWP 3730)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff65c7700 (LWP 3730)] 0x000000000045135b in ordered_value_match (match=0x7ffff65c56cc, ad=0x17c4, mr=0x92ddb0, flags=269, v1=0xcc0820, v2=0x7ffff65c56b0, text=0x7ffff65c6a90) at value.c:633 633 if ( ad->ad_type->sat_flags & SLAP_AT_ORDERED ) { (gdb) bt #0 0x000000000045135b in ordered_value_match (match=0x7ffff65c56cc, ad=0x17c4, mr=0x92ddb0, flags=269, v1=0xcc0820, v2=0x7ffff65c56b0, text=0x7ffff65c6a90) at value.c:633 #1 0x000000000044b71c in slap_sort_vals (ml=0xca8900, text=0x7ffff65c6a90, dup=0x7ffff65c587c, ctx=0x0) at modify.c:741 #2 0x000000000044b497 in slap_mods_check (op=0xaae2a0, ml=0xca8900, text=0x7ffff65c6a90, textbuf=0x7ffff65c6900 "", textlen=256, ctx=0x0) at modify.c:652 #3 0x000000000044a125 in do_modify (op=0xaae2a0, rs=0x7ffff65c6a70) at modify.c:168 #4 0x000000000042a7b0 in connection_operation (ctx=0x7ffff65c6ba0, arg_v=0xaae2a0) at connection.c:1150 #5 0x000000000042ad51 in connection_read_thread (ctx=0x7ffff65c6ba0, argv=0xd) at connection.c:1286 #6 0x00000000005ad930 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:688 #7 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #8 0x00007ffff7169b6d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) p ad $1 = (AttributeDescription *) 0x17c4 (gdb) p *ad Cannot access memory at address 0x17c4 (gdb)

1 0

Re: (ITS#7540) syncrepl "replicates" entries with unknown schema elements
by hyc＠symas.com 18 Mar '13

18 Mar '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.34 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) > > > This is similar to ITS#6473, but somewhat new and unique to back-mdb and > syncrepl fallback. > > If, during the process of upgrading a provider/replica cluster, a new schema > element is introduced to the provider, and a modification introducing a value > pair to that attribute is introduced to the provider prior to the replica having > its schema updated, very bad things happen. Don't turn schemacheck off in the consumer. -- -- 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#7541) nssov cannot create socket directory
by hyc＠symas.com 18 Mar '13

18 Mar '13

ryan.g.steele(a)gmail.com wrote: > Full_Name: Ryan Steele > Version: 2.4.34 > OS: Ubuntu, RedHat > URL: > Submission from: (NULL) (12.150.6.65) > > > According to https://github.com/gcp/openldap/blob/master/contrib/slapd-modules/nssov/nss…, > nssov tries to create the socket/PID directory /var/run/nslcd if it does not > exist. However, that mkdir attempt will always fail because slapd runs as a > non-privileged user and the permissions on /var/run are, appropriately, > root:root and 755. As a result, when a system using slapd+nssov is rebooted, > slapd fails to start and user lookups thusly fail until /var/run/nslcd is > manually created so that slapd can be started. Nonsense. That mkdir cannot cause slapd to fail to start, since its success/failure result is ignored. Take this up with your distro provider if the directory isn't available at start time. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7541) nssov cannot create socket directory
by ryan.g.steele＠gmail.com 18 Mar '13

18 Mar '13

Full_Name: Ryan Steele Version: 2.4.34 OS: Ubuntu, RedHat URL: Submission from: (NULL) (12.150.6.65) According to https://github.com/gcp/openldap/blob/master/contrib/slapd-modules/nssov/nss…, nssov tries to create the socket/PID directory /var/run/nslcd if it does not exist. However, that mkdir attempt will always fail because slapd runs as a non-privileged user and the permissions on /var/run are, appropriately, root:root and 755. As a result, when a system using slapd+nssov is rebooted, slapd fails to start and user lookups thusly fail until /var/run/nslcd is manually created so that slapd can be started. Traditionally, things in /var/run are created via init scripts, since they run as root. Once that is done, privileges can be dropped and the daemon started. Given that nssov is a contrib overlay, we could make a separate init script for nssov that runs before slapd's and creates the appropriate directory in /var/run. Alternatively, we could make --with-nslcd-pidfile and --with-nslcd-socket configurable post-install options instead of being set in stone at compile time, making it possible to set the PID/socket directory to something we know will exist and have the right perms, like /var/run/slapd (i.e., /var/run/slapd/nslcd.socket). It would probably make sense to remove the mkdir-related lines from nssov.c entirely, since non-privileged users do not have write perms on /var/run. I consider this a pretty serious issue, as it prevents the software from working.

1 0

(ITS#7540) syncrepl "replicates" entries with unknown schema elements
by quanah＠OpenLDAP.org 17 Mar '13

17 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181) This is similar to ITS#6473, but somewhat new and unique to back-mdb and syncrepl fallback. If, during the process of upgrading a provider/replica cluster, a new schema element is introduced to the provider, and a modification introducing a value pair to that attribute is introduced to the provider prior to the replica having its schema updated, very bad things happen. In essence, a control-charactered version of the attribute is introduced into the replica's DB. The value for the attribute is not necessarily the value that was written into the providers DB. The result is a somewhat corrupted DB on the replica. For example, when this occurs with an attribute with binary syntax, what we see on the replica is things like: ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000 in the slapcat output of the DB. Clearly these values are *not* binary, and the introduction of ^] (or sometimes ^Z) is clearly a very bad thing as well. On the provider, we see something like this in the accesslog: dn: reqStart=20130317181046.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20130317181046.000001Z reqEnd: 20130317181046.000002Z reqType: modify reqSession: 1001 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: cn=config,cn=zimbra reqResult: 0 reqMod: zimbraMobileMetadataMaxSizeEnabled:= FALSE reqMod: entryCSN:= 20130317181046.334253Z#000000#000#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20130317181046Z reqEntryUUID: c8e8ac5a-22de-1032-8b13-915a6d80e6d8 entryUUID: bc0a83f0-2379-1032-8335-47fcfae022fc creatorsName: cn=config createTimestamp: 20130317181046Z entryCSN: 20130317181046.334253Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130317181046Z However, as a part of this particular upgrade process, the accesslog DB was recreated (because of the MDB corruption issues). So delta-syncrepl "falls back" to normal syncrepl refresh mode. Instead of halting its fallback due to the missing schema entry, it *blindly* replicates the entire entry: Mar 17 11:10:47 zre-ldap003 slapd[8104]: do_syncrep2: rid=100 cookie=rid=100,csn=20130317181046.501990Z#000000#000#000000 Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8df54ac-22de-1032-8b02-915a6d80e6d8, dn cn=zimbra Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8df7662-22de-1032-8b03-915a6d80e6d8, dn cn=admins,cn=zimbra Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8dfa1fa-22de-1032-8b04-915a6d80e6d8, dn uid=zimbra,cn=admins,cn=zimbra Now when the DB is slapcat'd, we see: zimbra@zre-ldap003:~$ ./libexec/zmslapcat /tmp 51460a8c UNKNOWN attributeDescription "ZIMBRAMOBILEMETADATAMAXSIZEENABLED" inserted. And then in the entry itself we have: zimbraVersionCheckLastAttempt: 20130317011805Z zimbraVersionCheckLastSuccess: 20130317011805Z ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: FALSE ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000 zimbraRedoLogDeleteOnRollover: FALSE So syncrepl not only incorrectly replicated the entry with an unknown schema element, it corrupted the database in the process. Here is the actual data from the provider for this entry: zimbraVersionCheckLastAttempt: 20130317011805Z zimbraVersionCheckLastSuccess: 20130317011805Z zimbraMobileMetadataMaxSizeEnabled: FALSE zimbraHttpDosFilterMaxRequestsPerSec: 30 zimbraHttpDosFilterDelayMillis: -1 zimbraHttpThreadPoolMaxIdleTimeMillis: 10000 zimbraHttpConnectorMaxIdleTimeMillis: 60000 zimbraRedoLogDeleteOnRollover: FALSE --Quanah

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

--------------000301090802050902000107 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Howard, hyc(a)symas.com schrieb (14.03.2013 16:24 Uhr): > Marc Patermann wrote: >> hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): >>> hans.moser(a)ofd-z.niedersachsen.de wrote: >>>> I think we had situations like this before... >>>> >>>> How about having a test for this? >>>> What is the test which is nearest to this situation where a test could >>>> be based on? >>> test045. Feel free to submit patches for this test script. >> If I'm not mistaken, >> - in lines 262-264 the consumer is stopped >> - in lines 266-284 changes are made to the provider >> - in lines 286-294 the consumer is started again. > > Sounds reasonable but your line numbers don't match anything in our tree. > Please send an actual patch, e.g. from git format-patch (or just diff -u.) Sorry, I was in test054, not test045. But as base 054 seems to be just fine. I hope, I did the patch right. Marc --------------000301090802050902000107 Content-Type: text/x-patch; name="test-054.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test-054.patch" --- openldap-051dba8/tests/scripts/test054-syncreplication-parallel-load 2013-03-14 14:55:44.000000000 +0100 +++ test054-syncreplication-parallel-load 2013-03-14 17:16:25.516490000 +0100 @@ -236,6 +236,14 @@ dn: cn=James A Jones 2, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: delete +dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com +changetype: add +objectclass: OpenLDAPperson +cn: Invisible Man +sn: Man +uid: invisibleman +description: Ghost + EOMODS RC=$? @@ -281,6 +289,9 @@ uid: rosco cn: Rosco P. Coltrane +dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com +changetype: delete + EOMODS echo "Restarting consumer..." --------------000301090802050902000107--

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