- openldap-bugs - openldap.org

(ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 01 Mar '10

01 Mar '10

Full_Name: Himmelbauer Version: 2.4.19 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch Submission from: (NULL) (92.248.100.200) Was not able to retrieve database entries from a corrupted LDAP database using slapcat (openldap 2.4.19) with option -c. It aborts after the first corrupted entry with <= entry_decode: slap_str2undef_ad(object�!p): AttributeDescription contains inappropriate characters # no data for entry id=xxxxxxxx and doesn't continue with the next valid entry as I would have expected. A damaged database is not good, but as slapcat is described as the tool to recover the non-corrupted data in various forums, it would be good when it really continues on errors. Other ldap-related tools like ldapsearch ignore the damaged data, so it is really annoying, when you want to recover your data and don't even get all the readable entries. The patch corrects the handling of damaged entries by slapcat when -c is used, so that the output is continued with the next non-damaged entry. When -c is not used slapcat stops after the first corrupted entry (as expected). The patch works for me, but I know that it is not really correct, because when there would be no non-damaged entry left it would either cause a endless loop or some crashes. So a modification would be needed to stop the loop when the last database entry was processed, but I didn't know how to access that id.

1 0

slapadd problem
by tjoen 28 Feb '10

28 Feb '10

Openldap 2.4.21, patched with openldap-ntlm.diff from evolution ./configure --prefix=/usr --enable-static Db 4.7.25 ./configure --prefix=/usr --enable-compat185 --disable-static Problem with smbldap-populate: # smbldap-populate Populating LDAP directory for domain WORKGROUP (S-1-5-21-686817777-1585854605-660948164) (using builtin directory structure) adding new entry: dc=example,dc=org adding new entry: ou=People,dc=example,dc=org adding new entry: ou=Groups,dc=example,dc=org entry ou=People,dc=example,dc=org already exist. adding new entry: ou=Idmap,dc=example,dc=org ^C (hangs) test1.ldif: dn: dc=example,dc=org objectclass: dcObject objectclass: organization dc: example o: Quenya Org Network description: The Samba-3 Network LDAP Example test2.ldif: dn: sambaDomainName=WORKGROUP,dc=example,dc=org objectclass: top objectClass: sambaDomain objectClass: sambaUnixIdPool sambaDomainName: WORKGROUP sambaSID: S-1-5-21-686817777-1585854605-660948164 uidNumber: 1000 gidNumber: 1000 sambaNextRid: 1000 # /etc/rc.d/init.d/ldap stop /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... # slapadd -v -l test2.ldif ^C (hangs) But: /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test2.ldif added: "sambaDomainName=WORKGROUP,dc=example,dc=org" (00000002) _#################### 100.00% eta none elapsed none fast! Closing DB...Error, entries missing! entry 1: dc=example,dc=org # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... Why first test1 then test2 doesn't work? Deadlock? slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args loglevel 256 idletimeout 30 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth backend bdb database bdb cachesize 10000 suffix "dc=example,dc=org" checkpoint 1024 5 rootdn "cn=Manager,dc=example,dc=org" # /usr/sbin/slappasswd -s secret rootpw {SSHA}Z6Ton189xuv6t+OeUYxcGoLR+nZnh0Z6 directory /var/openldap-data # Indices to maintain index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub database monitor access to * by dn.exact="cn=Manager,dc=example,dc=org by * none

2 2

(ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com 25 Feb '10

25 Feb '10

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) When an URI is deferenced and when the server returns referals, an assertion is triggered in acl_set_cb_gather : assert( rs->sr_type == REP_RESULT ); It seems that sets don't handle the case where the search response is a REP_SEARCHREF. Regards, Raphaël Ouazana.

1 0

Re: ITS#6475
by manu＠netbsd.org 24 Feb '10

24 Feb '10

<masarati(a)aero.polimi.it> wrote: > It allows to configure what SASL auxprop names need the "dontUseCopy" > approach. The "cmusaslsecretOTP" is set by default, if known through the > schema. Seems nice. I hope I'll have time to test this week. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 24 Feb '10

24 Feb '10

A more complete fix is here: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-24-dontusecopy-…> It allows to configure what SASL auxprop names need the "dontUseCopy" approach. The "cmusaslsecretOTP" is set by default, if known through the schema. Please test. p.

1 0

ITS#6480
by masarati＠aero.polimi.it 22 Feb '10

22 Feb '10

Your analysis looks correct, but the solution is not: - If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is FALSE, the server MUST ignore the control. Your fix may result in not ignoring the control. A fix is coming. Thanks, p.

1 0

(ITS#6480) Incorrect handling of noncritical LDAP_CONTROL_X_SEARCH_OPTIONS
by alastair.mccormack＠ioko.com 22 Feb '10

22 Feb '10

Full_Name: Alastair McCormack Version: 2.3.43 OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.98.0.249) Proprietary LDAP Client ---LDAPv3---> OpenLDAP 2.3.43 Query: ??sub(objectClass=*) Client Receives Error 53: "searchOptions contained unrecognized flag" This works fine when client is pointed at a Windows AD Domain Controller. Tracing reveals that client is setting: Control: oid=1.2.840.113556.1.4.1340 = SERVER_SEARCH_FLAG_PHANTOM_ROOT noncritical By my novice understanding of the LDAP v3 RFC, the non-critical flag should mean that the search should not fail if the Control is not supported. However, it would seem that in controls.c an unknown or unimplemented flag is causing an exception even if the Control option is non critical. I have worked around this by creating and applying the following patch (includes typo fix): --- /var/tmp/controls.c-ignore-non-crit-search-flags 2010-02-22 15:16:16.000000000 +0000 +++ openldap-2.3.43/servers/slapd/controls.c 2008-04-09 02:12:47.000000000 +0100 @@ -1425,10 +1425,10 @@ static int parseSearchOptions ( : SLAP_CONTROL_NONCRITICAL; } - if ( search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE) ) { + if ( (search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE)) && ctrl->ldctl_iscritical ) { /* Other search flags not recognised so far, * including: - * LDAP_SEARCH_FLAG_PHANTOM_ROOM + * LDAP_SEARCH_FLAG_PHANTOM_ROOT */ rs->sr_text = "searchOptions contained unrecognized flag"; return LDAP_UNWILLING_TO_PERFORM; I have very little C knowledge so this was more of a POC rather than a suggested solution. Many thanks for a superb application. Keep up the good work :) Alastair McCormack

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 21 Feb '10

21 Feb '10

That's it, Thank you. hellweiss > You need to add (before "olcAccess: {3}") something that allows search > access to any valid search base. OpenLDAP 2.4 requires search access to > the entry pseudo-attribute of the search base. > > Something like > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > p. > -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

ITS#6475
by masarati＠aero.polimi.it 21 Feb '10

21 Feb '10

The "easy" fix is here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecopy-…> I haven't committed it (needs some polishing) because it touches slapo-chain(5) in a couple of places, and I'd rather be sure it does not break anything. I won't be able to work at it for a while. It needs some polishing (SASL attributes that may need dontUseCopy should be at least configurable and so). Please test.

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 20 Feb '10

20 Feb '10

You need to add (before "olcAccess: {3}") something that allows search access to any valid search base. OpenLDAP 2.4 requires search access to the entry pseudo-attribute of the search base. Something like olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read p.

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 20 Feb '10

20 Feb '10

> > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > > attrs=cn,email,entry,objectClass,uid by * read > > > > works ok, changing the olcAccess filter to e.g. person > > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > > attrs=cn,email,entry,objectClass,uid by * read > > > > gives no results > > Given that this is specifically tested by test006, and this test routinely > passes, and considering how incomplete your report is, I recommend you > provide a means to easily reproduce the issue (e.g. detailed slapd.conf, > LDIF data and details about the unsuccessful operation) in order to have > this issue report processed further. > > p. Hello p., so, if I got you right, this 'test006' states, that this must be a configuration error and I better move on to the support Mailinglist or somewhere else. If this should not be the case, here's what i've got: There's no slapd.conf, it's empty # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=site olcRootDN: cn=admin,dc=site olcRootPW: xxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to dn.subtree="dc=site" filter=(objectclass=inetOrgPerson) attrs =cn,email,entry,objectClass,uid by * read olcAccess: {4}to * by * none I've only access to the test system now, so the dc and objectclass is different. Here is the only user: # test, people, site dn: uid=test,ou=people,dc=site cn: test test gidNumber: 100 givenName: test homeDirectory: /home/test loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: inetOrgPerson sn: test uid: test uidNumber: 1001 If I do an ldapsearch -x -b ou=people,dc=site or as test User there are no results. What I want to achieve is Anonymous and User read access only to inetOrgPerson Entries and special attributes, nothing else. No groupOfNames or device Entries in the subtree. Regards Hellweiss -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

> Full_Name: hellweiss > Version: 2.4.20 > OS: openSuSE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.135.6.106) > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > attrs=cn,email,entry,objectClass,uid by * read > > works ok, changing the olcAccess filter to e.g. person > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > attrs=cn,email,entry,objectClass,uid by * read > > gives no results Given that this is specifically tested by test006, and this test routinely passes, and considering how incomplete your report is, I recommend you provide a means to easily reproduce the issue (e.g. detailed slapd.conf, LDIF data and details about the unsuccessful operation) in order to have this issue report processed further. p.

1 0

(ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 19 Feb '10

19 Feb '10

Full_Name: hellweiss Version: 2.4.20 OS: openSuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.135.6.106) olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) attrs=cn,email,entry,objectClass,uid by * read works ok, changing the olcAccess filter to e.g. person olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) attrs=cn,email,entry,objectClass,uid by * read gives no results

1 0

Re: (ITS#6478) slapd crashes with segfault
by quanah＠zimbra.com 19 Feb '10

19 Feb '10

--On Friday, February 19, 2010 2:18 PM +0000 wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) Please provide a backtrace from a version of slapd compiled with full debugging symbols (CFLAGS="-g"). Your report is too vague to provide any help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) > > > OpenLdap crashes occasionally with a segfault error, e.g. > [root@ts2mstsv010 Ldap]# dmesg|grep slapd > slapd[8783]: segfault at 00000000000000f0 rip 0000000000459b72 rsp > 000000004286e990 error 4 > [root@ts2mstsv010 Ldap]# > After the crash, stale lock files exist, slapd_db_recover has to be run > The server is HP D380 G5 with Intel Quadcore CPU @ 2 GHz > 32 GB memory > OS is Linux Redhat 64bit 5.1 > Oracle Berkeley DB is 4.7 > The server has 5 DBs. The whole setup has a second master in identical config > with multi-master replication and 2 slaves. > The 2 main DBs have 30 Mio. entries each, the other dbs are very small. > <http://www.openldap.org/faq/data/cache/59.html> p.

1 0

(ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 19 Feb '10

19 Feb '10

Full_Name: Wolfgang Hummel Version: 2.4.21 OS: RedHat Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.80) OpenLdap crashes occasionally with a segfault error, e.g. [root@ts2mstsv010 Ldap]# dmesg|grep slapd slapd[8783]: segfault at 00000000000000f0 rip 0000000000459b72 rsp 000000004286e990 error 4 [root@ts2mstsv010 Ldap]# After the crash, stale lock files exist, slapd_db_recover has to be run The server is HP D380 G5 with Intel Quadcore CPU @ 2 GHz 32 GB memory OS is Linux Redhat 64bit 5.1 Oracle Berkeley DB is 4.7 The server has 5 DBs. The whole setup has a second master in identical config with multi-master replication and 2 slaves. The 2 main DBs have 30 Mio. entries each, the other dbs are very small.

1 0

(ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by bseklecki＠noc.cfi.pgh.pa.us 18 Feb '10

18 Feb '10

Full_Name: Brian A. Seklecki Version: 2.4.21 OS: FreeBSD, Linux, Plan 9, CP/M, Bubble Memory URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f000:10:202:21a:a0ff:fec2:7a6c) I'll try not to be ambiguous in my bug report. We received a support request escalation regarding an ambiguous error printed by slapd(8) at init. After review, we found that SSL library calls in OpenLDAP are not properly reporting back to the user fopen() problems when TLSCert* configuration objects are unreadable by the effective POSIX user. E.g., when a private key/cert/intermediary cert chain has POSIX permissions restricting read access by "-u $USER", the following error is printed: User Steve Polyack reports a similar error here: http://www.openldap.org/lists/openldap-software/201002/msg00025.html Also Google says: Results 1-10 of about 1,730 for "main: TLS init def ctx failed: -1". Some of these result all the back to early 2003 If you look at mailing list archives, similar error reports appear thousands of times from confused users who thought they were being diligent in by setting restrictive permissions only to receive an ambiguous error that indicates nothing about excessively restrictive permissions. The problem is that this error gets printed with "-1" under too many conditions in libraries/libldap/tls2.c::ldap_pvt_tls_set_option() ...which in turn sets rc= in servers/slapd/main.c: Which prints: 2010 Feb 5 10:52:34 -08:00 host [slapd][6261] [local4] [debug] slapd[6261]: main: TLS init def ctx failed: -1 So unless you've browsed through the OpenSSL API guide, you wouldn't even know what the CTX data structure is or how it relates to this. They do a pretty shitty job of explaining it even, so why bother mentioning it? Anyway, until we can implement OpenSSL's err(3) framework, we should refer to the user to ssl.h for RC values from ldap_pvt_tls_set_option() greater than 0. For errors, greater than 1, ldap_pvt_tls_set_option() can return that in about 15 different locations. It _could also_ pass on a -1 return code from ldap_int_tls_init_ctx () at: return ldap_int_tls_init_ctx( lo, *(int *)arg ); There are no shortage of places where where -1 could be returned to user in our code, so we should make -1 return codes other negative values to nudge the user along. Additional Debug() statements would be useful, but I don't want to get greedy. ~BAS ----------------- These patches compile-test. I'll push them into our pre-production environment: $ diff -u servers/slapd/main.c-orig servers/slapd/main.c --- servers/slapd/main.c-orig 2010-02-18 16:52:37.000000000 -0500 +++ servers/slapd/main.c 2010-02-18 16:57:30.000000000 -0500 @@ -843,8 +843,16 @@ load_extop( &slap_EXOP_START_TLS, 0, starttls_extop ); } else if ( rc != LDAP_NOT_SUPPORTED ) { Debug( LDAP_DEBUG_ANY, - "main: TLS init def ctx failed: %d\n", + "main: TLS initialization of def SSL/TLS CTX object failed with err: %d\n", rc, 0, 0 ); + + if (rc < 0) { + Debug( LDAP_DEBUG_ANY, "main: something has gone terribly wrong in creation of the SSL data structure. Check filesystem permissions, ownership bits, ACLs, configuration file paths. Resort to strace(1)/ktrace(1) debugging.\n", rc, 0, 0); + } + if (rc > 0) { + Debug( LDAP_DEBUG_ANY, "main: something has gone wrong in creation of the SSL socket data structure. Please check the OpenSSL error code above against: /usr/include/openssl/ssl until we add err(3) support.\n", rc, 0, 0); + } + rc = 1; SERVICE_EXIT( ERROR_SERVICE_SPECIFIC_ERROR, 20 ); goto destroy; $ diff -u ./libraries/libldap/tls2.c-orig ./libraries/libldap/tls2.c --- ./libraries/libldap/tls2.c-orig 2010-02-18 17:14:59.000000000 -0500 +++ ./libraries/libldap/tls2.c 2010-02-18 17:16:25.000000000 -0500 @@ -704,7 +704,7 @@ switch( option ) { case LDAP_OPT_X_TLS: - if ( !arg ) return -1; + if ( !arg ) return -2; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_NEVER: @@ -718,7 +718,7 @@ return 0; } - return -1; + return -3; case LDAP_OPT_X_TLS_CTX: if ( lo->ldo_tls_ctx ) @@ -757,7 +757,7 @@ lo->ldo_tls_crlfile = arg ? LDAP_STRDUP( (char *) arg ) : NULL; return 0; case LDAP_OPT_X_TLS_REQUIRE_CERT: - if ( !arg ) return -1; + if ( !arg ) return -3; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_NEVER: case LDAP_OPT_X_TLS_DEMAND: @@ -767,10 +767,10 @@ lo->ldo_tls_require_cert = * (int *) arg; return 0; } - return -1; + return -4; #ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ - if ( !arg ) return -1; + if ( !arg ) return -5; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_CRL_NONE: case LDAP_OPT_X_TLS_CRL_PEER: @@ -778,7 +778,7 @@ lo->ldo_tls_crlcheck = * (int *) arg; return 0; } - return -1; + return -6; #endif case LDAP_OPT_X_TLS_CIPHER_SUITE: if ( lo->ldo_tls_ciphersuite ) LDAP_FREE( lo->ldo_tls_ciphersuite ); @@ -786,17 +786,17 @@ return 0; case LDAP_OPT_X_TLS_PROTOCOL_MIN: - if ( !arg ) return -1; + if ( !arg ) return -7; lo->ldo_tls_protocol_min = *(int *)arg; return 0; case LDAP_OPT_X_TLS_RANDOM_FILE: if ( ld != NULL ) - return -1; + return -8; if ( lo->ldo_tls_randfile ) LDAP_FREE (lo->ldo_tls_randfile ); lo->ldo_tls_randfile = arg ? LDAP_STRDUP( (char *) arg ) : NULL; break; case LDAP_OPT_X_TLS_NEWCTX: - if ( !arg ) return -1; + if ( !arg ) return -9; if ( lo->ldo_tls_ctx ) ldap_pvt_tls_ctx_free( lo->ldo_tls_ctx ); lo->ldo_tls_ctx = NULL;

1 0

Re: (ITS#6464) Buffer overflow
by rhafer＠suse.de 17 Feb '10

17 Feb '10

Am Mittwoch 17 Februar 2010 11:57:27 schrieb csdr(a)lthd.com: > Well .. it worked. > > Here are that stack traces if you need them anymore (I thought strace > did that) ... > > http://www.lthd.com/thread_apply_all_bt.txt > and > http://www.lthd.com/bt_full.txt > > Thank you. > > PS: I am surprised that none has encountered that bug which comes from > version 2.4.19 (AFAIK) This problem only appears when using pretty recent gcc Versions and when building with -D_FORTIFY_SOURCE=2 (At least for me). -- Ralf

1 0

(ITS#6476) Failure to delete entry with multi-master replication
by worganc＠avaya.com 17 Feb '10

17 Feb '10

Full_Name: Craig Worgan Version: 2.4.21 OS: RedHat Enterprise Linux 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.86) As per Kyle Blaney's post to the bugs mailing list (Kyle is n vacation so I am submitting this ITS on his behalf): I have encountered a situation with multi-master replication in OpenLDAP 2.4.21 where an entry deleted on one server is not deleted from its peer. I'm using Redhat Enterprise Linux 5. Here's what I did: 1. Configure Network Time Protocol with server A as the NTP master and server B as the NTP slave. 2. Configure multi-master replication between server A (server ID=1) and server B (server ID=2). 3. Start OpenLDAP service on servers A and B. 4. Add an entry to server A and ensure it's replicated to server B. 5. Add an entry to server B and ensure it's replicated to server A. 6. Stop OpenLDAP service on server A. 7. Delete an entry on server B. 8. Start OpenLDAP service on server A with sync debugging enabled (-d sync). At this point, I expected that the entry deleted from server B would be deleted from server A. Instead, the entry remained on server A and slapd displayed the following (with the entry's DN X'ed out): slapd starting do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Entry XXXXXX CSN 20100209193028.621799Z#000000#001#000000 older or equal to ctx 20100209193028.621799Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20100202210831.101462Z#000000#000#000000;2010 0209193028.621799Z#000000#001#000000;20100209193118.342038Z#000000#002#0 00000 Why wouldn't the entry deleted on server B also deleted from server A? Is the failure to delete the entry related to the "entry CSN older or equal to context CSN" message? Unfortunately, I have been unable to reproduce the failure since I first saw it. All subsequent tests have shown that the entry deleted from server B is deleted from server A when the OpenLDAP service on server A is restarted. Kyle Blaney ------------------------------------------------------------------------- There is also this follow up post: I can now reliably reproduce this problem in 2.4.21 and 2.4.20 on a multi-master setup that only has five entries: 1. Stop service on server A. 2. Delete one entry on server B. 3. Start service on server A. After step 3, the entry is never deleted from server A. I have changed many aspects of configuration (replication with and without TLS, syncprov-sessionlog enabled and disabled, syncprov-checkpoint enabled and disabled, syncprov-nopresent TRUE and FALSE, syncprov-reloadhint TRUE and FALSE) and the problem still occurs. Is this problem the same one outlined in "test 058 failure" at http://www.openldap.org/lists/openldap-software/201002/msg00031.html? Kyle ---------------------------------------------------------------------- Thanks, Craig Worgan

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 17 Feb '10

17 Feb '10

Well .. it worked. Here are that stack traces if you need them anymore (I thought strace did that) ... http://www.lthd.com/thread_apply_all_bt.txt and http://www.lthd.com/bt_full.txt Thank you. PS: I am surprised that none has encountered that bug which comes from version 2.4.19 (AFAIK)

1 0

Re: (ITS#6464) Buffer overflow
by Ralf Haferkamp 17 Feb '10

17 Feb '10

> Sorry. > I hope this helps: http://lthd.com/slapd.out Hm, that's not a stack backtrace (http://www.openldap.org/faq/index.cgi?file=59), but not apart from that, it looks like you are hit by ITS#6474. Please test again with current HEAD. Or apply the changes between 1.168 and 1.169 of servers/slapd/back-bdb/dn2id.c from CVS to your 2.4.21 release: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/dn2id.c.dif… r1=1.168&r2=1.169&hideattic=1&sortbydate=0&f=h -- Ralf

1 0

(ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org 16 Feb '10

16 Feb '10

Full_Name: Emmanuel Dreyfus Version: any OS: any URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz Submission from: (NULL) (213.41.141.172) When binding using SASL OTP to a replica, the bind works, but the cmusaslsecretOTP attribute is modified on the replica and fail to be propagated to the master. On the next modification, the master will overwrite the replica's updated cmusaslsecretOTP value. Here is a script that exhibit the behaviour: ftp://ftp.openldap.org/incoming/ldapotp.tgz That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in run.sh must probably be adjusted.

1 0

(ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 15 Feb '10

15 Feb '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: linux (gcc 4.5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.207.32) Submitted by: ralf gcc 4.5 will do some stricter checks for buffer overflows when compiling with -D_FORTIFY_SOURCE=2. Current HEAD aborts in test004-modify with: *** buffer overflow detected ***: /usr/src/packages/BUILD/openldap-2.4.21/servers/slapd/.libs/slapd terminated ======= Backtrace: ========= #0 0x00007f207dc6b9c5 in raise () from /lib64/libc.so.6 #1 0x00007f207dc6ced6 in abort () from /lib64/libc.so.6 #2 0x00007f207dca6ba9 in __libc_message () from /lib64/libc.so.6 #3 0x00007f207dd20537 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007f207dd1e2e0 in __chk_fail () from /lib64/libc.so.6 #5 0x00007f207fa89769 in strcpy () at dn2id.c:679 There is no real buffer overflow here AFAICS but the real problem is, that the destination of the strcpy() is defined as char[1] in this case (it's the nrdn member of a struct diskNode). The additional runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the destination data will not fit in there and aborts. The easiest fix here (apart from not building with -D_FORTIFY_SOURCE=2) is to use memcpy instead of strcpy here. I'll submit that later today.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 15 Feb '10

15 Feb '10

Hello again. We randomly tried to switch to LDAP without SSL last Friday (we used ldaps://..:636/ before), and the server hasn't crashed since! This is a good enough workaround for us, but I hope this information can help with fixing this bug, or help others with the same problem. On Wed, Dec 30, 2009 at 02:08:00PM +0100, Helge Milde wrote: >On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>I just enabled trace loglevel, perhaps that might give us a clue on what's going on. > >Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading: >http://www.pastie.org/761198.txt > >Does this give you any clues? > >Tell me if I can do anything else to help. > >-- >Helge Milde, 69701808 >www.monsternett.no -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

If nothing else, if this is in fact some strange 'elusive' bug, someone = else experiencing it may find this thread useful or enlightening in some = way (or perhaps it may help them further identify the particulars of = this intermittent phenomenon). I too must avoid spending further time = on this issue, as my team considers it suitably fixed; thus not = requiring further invested resources on my part. Thanks for your time on this issue, I must move on now. J=

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs