openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(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

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

Marc Patermann wrote: > Howard, > > 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.) > > But the changes do > - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > (lines 269-270) > - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, > dc=example,dc=com (lines 272-275) > - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > _again_ (lines 277-282) > So while the consumer is down Coltrane is deleted and added again. > We miss a scenario where an object is still deleted, when the consumer > is back again. > > There is no object, which is not used later on, so we should add a new > object first: > > (before line 239) > > 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 > > And delete the object while the consumer is down: > > (before line 284) > > dn: cn=Invisible Man, ou=Information Technology Division, ou=People, > dc=example,dc=com > changetype: delete > > > That would do, I think. > > > Sorry for not patching it myself, I'm not too familiar with it. > > > Marc > -- -- 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#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

Howard, 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. But the changes do - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com (lines 269-270) - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com (lines 272-275) - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com _again_ (lines 277-282) So while the consumer is down Coltrane is deleted and added again. We miss a scenario where an object is still deleted, when the consumer is back again. There is no object, which is not used later on, so we should add a new object first: (before line 239) 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 And delete the object while the consumer is down: (before line 284) dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: delete That would do, I think. Sorry for not patching it myself, I'm not too familiar with it. Marc

1 0

Re: (ITS#7528) ldapadd not working while adding attribute having long list of values
by hyc＠symas.com 14 Mar '13

14 Mar '13

omkar(a)mithi.com wrote: > Full_Name: Omkar Phadke > Version: 2.4.30 > OS: Red Hat Enterprise Linux Server release 6.0 (Santiago) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.111.211.142) > > > I am trying to add bellow ldif file. Read the ldif(5) manpage. You appear to have line breaks in the data which breaks the format. -- -- 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#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

hans.moser(a)ofd-z.niedersachsen.de wrote: > Hi, > > jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > >> The setup is a master with an ldap backend and a slave consumer. If the master >> is running and slave is not, delete operation results in the master being >> stuck. A patch for this is now in git master, please test. > 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. -- -- 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

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